home *** CD-ROM | disk | FTP | other *** search
Text File | 1997-08-06 | 162.4 KB | 4,596 lines |
-
-
-
-
-
-
- Network Working Group K. de Graaf
- Request for Comments: 2108 3Com Corporation
- Obsoletes: 1516 D. Romascanu
- Category: Standards Track Madge Networks (Israel) Ltd.
- D. McMaster
- Coloma Communications
- K. McCloghrie
- Cisco Systems Inc.
- February 1997
-
-
- Definitions of Managed Objects
- for IEEE 802.3 Repeater Devices
- using SMIv2
-
- Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
- Abstract
-
- This memo defines a portion of the Management Information Base (MIB)
- for use with network management protocols in the Internet community.
- In particular, it defines objects for managing IEEE 802.3 10 and 100
- Mb/second baseband repeaters based on IEEE Std 802.3 Section 30, "10
- & 100 Mb/s Management," October 26, 1995.
-
- Table of Contents
-
- 1. The SNMP Network Management Framework.................... 2
- 1.1. Object Definitions..................................... 2
- 2. Overview................................................. 2
- 2.1. Relationship to RFC 1516............................... 2
- 2.2. Repeater Management.................................... 3
- 2.3. Structure of the MIB................................... 4
- 2.3.1. Basic Definitions.................................... 4
- 2.3.2. Monitor Definitions.................................. 4
- 2.3.3. Address Tracking Definitions......................... 4
- 2.3.4. Top N Definitions.................................... 4
- 2.4. Relationship to Other MIBs............................. 4
- 2.4.1. Relationship to MIB-II............................... 4
- 2.4.1.1. Relationship to the 'system' group................. 5
- 2.4.1.2. Relationship to the 'interfaces' group............. 5
- 3. Definitions............................................... 6
-
-
-
- de Graaf, et. al. Standards Track [Page 1]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- 4. Topology Mapping......................................... 75
- 5. Acknowledgements......................................... 79
- 6. References............................................... 80
- 7. Security Considerations.................................. 81
- 8. Authors' Addresses....................................... 81
-
- 1. The SNMP Network Management Framework
-
- The SNMP Network Management Framework presently consists of three
- major components. They are:
-
- o the SMI, described in RFC 1902 [6] - the mechanisms used
- for describing and naming objects for the purpose of
- management.
-
- o the MIB-II, STD 17, RFC 1213 [5] - the core set of
- managed objects for the Internet suite of protocols.
-
- o the protocol, STD 15, RFC 1157 [10] and/or RFC 1905
- [9] - the protocol used for accessing managed information.
-
- Textual conventions are defined in RFC 1903 [7], and conformance
- statements are defined in RFC 1904 [8].
-
- The Framework permits new objects to be defined for the purpose of
- experimentation and evaluation.
-
- 1.1. Object Definitions
-
- Managed objects are accessed via a virtual information store, termed
- the Management Information Base or MIB. Objects in the MIB are
- defined using the subset of Abstract Syntax Notation one (ASN.1)
- defined in the SMI. In particular, each object type is named by an
- OBJECT IDENTIFIER, an administratively assigned name. The object
- type together with an object instance serves to uniquely identify a
- specific instantiation of the object. For human convenience, we
- often use a textual string, termed the descriptor, to refer to the
- object type.
-
- 2. Overview
-
- 2.1. Relationship to RFC 1516
-
- This MIB is intended as a superset of that defined by RFC 1516 [11],
- which will go to historic status. This MIB includes all of the
- objects contained in that MIB, plus several new ones which provide
-
-
-
-
-
- de Graaf, et. al. Standards Track [Page 2]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- for significant additional capabilities. Implementors are encouraged
- to support all applicable conformance groups in order to make the
- best use of the new functionality provided by this MIB. The new
- objects provide support for:
-
- o multiple repeaters
-
- o 100BASE-T management
-
- o port TopN capability
-
- o address search and topology mapping
-
- Certain objects have been deprecated; in particular, those scalar
- objects used for managing a single repeater are now of minimal use
- since they are duplicated in the new multiple- repeater definitions.
- Additional objects have been deprecated based on implementation
- experience with RFC 1516.
-
- 2.2. Repeater Management
-
- Instances of the object types defined in this memo represent
- attributes of an IEEE 802.3 (Ethernet-like) repeater, as defined by
- Section 9, "Repeater Unit for 10 Mb/s Baseband Networks" in the IEEE
- 802.3/ISO 8802-3 CSMA/CD standard [1], and Section 27, "Repeater for
- 100 Mb/s Baseband Networks" in the IEEE Standard 802.3u-1995 [2].
-
- These Repeater MIB objects may be used to manage non-standard
- repeater-like devices, but defining objects to describe
- implementation-specific properties of non-standard repeater- like
- devices is outside the scope of this memo.
-
-
- The definitions presented here are based on Section 30.4, "Layer
- Management for 10 and 100 Mb/s Baseband Repeaters" and Annex 30A,
- "GDMO Specificataions for 802.3 managed objects" of [3].
-
- Implementors of these MIB objects should note that [3] explicitly
- describes when, where, and how various repeater attributes are
- measured. The IEEE document also describes the effects of repeater
- actions that may be invoked by manipulating instances of the MIB
- objects defined here.
-
- The counters in this document are defined to be the same as those
- counters in [3], with the intention that the same instrumentation can
- be used to implement both the IEEE and IETF management standards.
-
-
-
-
-
- de Graaf, et. al. Standards Track [Page 3]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- 2.3. Structure of the MIB
-
- Objects in this MIB are arranged into packages, each of which
- contains a set of related objects within a broad functional category.
- Objects within a package are generally defined under the same OID
- subtree. These packages are intended for organizational convenience
- ONLY, and have no relation to the conformance groups defined later in
- the document.
-
- 2.3.1. Basic Definitions
-
- The basic definitions include objects which are applicable to all
- repeaters: status, parameter and control objects for each repeater
- within the managed system, for the port groups within the system, and
- for the individual ports themselves.
-
- 2.3.2. Monitor Definitions
-
- The monitor definitions include monitoring statistics for each
- repeater within the system and for individual ports.
-
- 2.3.3. Address Tracking Definitions
-
- This collection includes objects for tracking the MAC addresses of
- the DTEs attached to the ports within the system and for mapping the
- topology of a network.
-
- Note: These definitions are based on a technology which has been
- patented by Hewlett-Packard Company. HP has granted rights to this
- technology to implementors of this MIB. See [12] and [13] for
- details.
-
- 2.3.4. Top N Definitions
-
- These objects may be used for tracking the ports with the most
- activity within the system or within particular repeaters.
-
- 2.4. Relationship to Other MIBs
-
- 2.4.1. Relationship to MIB-II
-
- It is assumed that a repeater implementing this MIB will also
- implement (at least) the 'system' group defined in MIB-II [5].
-
-
-
-
-
-
-
-
- de Graaf, et. al. Standards Track [Page 4]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- 2.4.1.1. Relationship to the 'system' group
-
- In MIB-II, the 'system' group is defined as being mandatory for all
- systems such that each managed entity contains one instance of each
- object in the 'system' group. Thus, those objects apply to the
- entity even if the entity's sole functionality is management of
- repeaters.
-
- 2.4.1.2. Relationship to the 'interfaces' group
-
- In MIB-II, the 'interfaces' group is defined as being mandatory for
- all systems and contains information on an entity's interfaces, where
- each interface is thought of as being attached to a 'subnetwork'.
- (Note that this term is not to be confused with 'subnet' which refers
- to an addressing partitioning scheme used in the Internet suite of
- protocols.)
-
- This Repeater MIB uses the notion of ports on a repeater. The
- concept of a MIB-II interface has NO specific relationship to a
- repeater's port. Therefore, the 'interfaces' group applies only to
- the one (or more) network interfaces on which the entity managing the
- repeater sends and receives management protocol operations, and does
- not apply to the repeater's ports.
-
- This is consistent with the physical-layer nature of a repeater. A
- repeater is a bitwise store-and-forward device. It recognizes
- activity and bits, but does not process incoming data based on any
- packet-related information (such as checksum or addresses). A
- repeater has no MAC address, no MAC implementation, and does not pass
- packets up to higher-level protocol entities for processing.
-
- (When a network management entity is observing a repeater, it may
- appear as though the repeater is passing packets to a higher-level
- protocol entity. However, this is only a means of implementing
- management, and this passing of management information is not part of
- the repeater functionality.)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- de Graaf, et. al. Standards Track [Page 5]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- 3. Definitions
-
- SNMP-REPEATER-MIB DEFINITIONS ::= BEGIN
-
- IMPORTS
- Counter32, Counter64, Integer32, Gauge32, TimeTicks,
- OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, mib-2
- FROM SNMPv2-SMI
- TimeStamp, DisplayString, MacAddress, TEXTUAL-CONVENTION,
- RowStatus, TestAndIncr
- FROM SNMPv2-TC
- OBJECT-GROUP, MODULE-COMPLIANCE
- FROM SNMPv2-CONF
- OwnerString
- FROM IF-MIB;
-
-
- snmpRptrMod MODULE-IDENTITY
- LAST-UPDATED "9609140000Z"
- ORGANIZATION "IETF HUB MIB Working Group"
- CONTACT-INFO
- "WG E-mail: hubmib@hprnd.rose.hp.com
-
- Chair: Dan Romascanu
- Postal: Madge Networks (Israel) Ltd.
- Atidim Technology Park, Bldg. 3
- Tel Aviv 61131, Israel
- Tel: 972-3-6458414, 6458458
- Fax: 972-3-6487146
- E-mail: dromasca@madge.com
-
- Editor: Kathryn de Graaf
- Postal: 3Com Corporation
- 118 Turnpike Rd.
- Southborough, MA 01772 USA
- Tel: (508)229-1627
- Fax: (508)490-5882
- E-mail: kdegraaf@isd.3com.com"
- DESCRIPTION
- "Management information for 802.3 repeaters.
-
- The following references are used throughout
- this MIB module:
-
- [IEEE 802.3 Std]
- refers to IEEE 802.3/ISO 8802-3 Information
- processing systems - Local area networks -
- Part 3: Carrier sense multiple access with
-
-
-
- de Graaf, et. al. Standards Track [Page 6]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- collision detection (CSMA/CD) access method
- and physical layer specifications (1993).
-
- [IEEE 802.3 Mgt]
- refers to IEEE 802.3u-1995, '10 Mb/s &
- 100 Mb/s Management, Section 30,'
- Supplement to ANSI/IEEE 802.3.
-
- The following terms are used throughout this
- MIB module. For complete formal definitions,
- the IEEE 802.3 standards should be consulted
- wherever possible:
-
- System - A managed entity compliant with this
- MIB, and incorporating at least one managed
- 802.3 repeater.
-
- Chassis - An enclosure for one managed repeater,
- part of a managed repeater, or several managed
- repeaters. It typically contains an integral
- power supply and a variable number of available
- module slots.
-
- Repeater-unit - The portion of the repeater set
- that is inboard of the physical media interfaces.
- The physical media interfaces (MAUs, AUIs) may be
- physically separated from the repeater-unit, or
- they may be integrated into the same physical
- package.
-
- Trivial repeater-unit - An isolated port that can
- gather statistics.
-
- Group - A recommended, but optional, entity
- defined by the IEEE 802.3 management standard,
- in order to support a modular numbering scheme.
- The classical example allows an implementor to
- represent field-replaceable units as groups of
- ports, with the port numbering matching the
- modular hardware implementation.
-
- System interconnect segment - An internal
- segment allowing interconnection of ports
- belonging to different physical entities
- into the same logical manageable repeater.
- Examples of implementation might be
- backplane busses in modular hubs, or
- chaining cables in stacks of hubs.
-
-
-
- de Graaf, et. al. Standards Track [Page 7]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- Stack - A scalable system that may include
- managed repeaters, in which modularity is
- achieved by interconnecting a number of
- different chassis.
-
- Module - A building block in a modular
- chassis. It typically maps into one 'slot';
- however, the range of configurations may be
- very large, with several modules entering
- one slot, or one module covering several
- slots.
- "
- REVISION "9309010000Z"
- DESCRIPTION
- "Published as RFC 1516"
- REVISION "9210010000Z"
- DESCRIPTION
- "Published as RFC 1368"
- ::= { snmpDot3RptrMgt 5 }
-
-
-
- snmpDot3RptrMgt OBJECT IDENTIFIER ::= { mib-2 22 }
-
-
- OptMacAddr ::= TEXTUAL-CONVENTION
- DISPLAY-HINT "1x:"
- STATUS current
- DESCRIPTION
- "Either a 6 octet address in the `canonical'
- order defined by IEEE 802.1a, i.e., as if it
- were transmitted least significant bit first
- if a value is available or a zero length string."
- REFERENCE
- "See MacAddress in SNMPv2-TC. The only difference
- is that a zero length string is allowed as a value
- for OptMacAddr and not for MacAddress."
- SYNTAX OCTET STRING (SIZE (0 | 6))
-
-
-
- -- Basic information at the repeater, group, and port level.
-
- rptrBasicPackage
- OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 1 }
- rptrRptrInfo
- OBJECT IDENTIFIER ::= { rptrBasicPackage 1 }
- rptrGroupInfo
-
-
-
- de Graaf, et. al. Standards Track [Page 8]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- OBJECT IDENTIFIER ::= { rptrBasicPackage 2 }
- rptrPortInfo
- OBJECT IDENTIFIER ::= { rptrBasicPackage 3 }
- rptrAllRptrInfo
- OBJECT IDENTIFIER ::= { rptrBasicPackage 4 }
-
- -- Monitoring information at the repeater, group, and port level.
- rptrMonitorPackage
- OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 2 }
- rptrMonitorRptrInfo
- OBJECT IDENTIFIER ::= { rptrMonitorPackage 1 }
- rptrMonitorGroupInfo
- OBJECT IDENTIFIER ::= { rptrMonitorPackage 2 }
- rptrMonitorPortInfo
- OBJECT IDENTIFIER ::= { rptrMonitorPackage 3 }
- rptrMonitorAllRptrInfo
- OBJECT IDENTIFIER ::= { rptrMonitorPackage 4 }
-
- -- Address tracking information at the repeater, group,
- -- and port level.
- rptrAddrTrackPackage
- OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 3 }
- rptrAddrTrackRptrInfo
- OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 1 }
- rptrAddrTrackGroupInfo
- -- this subtree is currently unused
- OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 2 }
- rptrAddrTrackPortInfo
- OBJECT IDENTIFIER ::= { rptrAddrTrackPackage 3 }
-
- -- TopN information.
- rptrTopNPackage
- OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 4 }
- rptrTopNRptrInfo
- -- this subtree is currently unused
- OBJECT IDENTIFIER ::= { rptrTopNPackage 1 }
- rptrTopNGroupInfo
- -- this subtree is currently unused
- OBJECT IDENTIFIER ::= { rptrTopNPackage 2 }
- rptrTopNPortInfo
- OBJECT IDENTIFIER ::= { rptrTopNPackage 3 }
-
-
- -- Old version of basic information at the repeater level.
- --
- -- In a system containing a single managed repeater,
- -- configuration, status, and control objects for the overall
- -- repeater.
-
-
-
- de Graaf, et. al. Standards Track [Page 9]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- --
- -- The objects contained under the rptrRptrInfo subtree are
- -- intended for backwards compatibility with implementations of
- -- RFC 1516 [11]. In newer implementations (both single- and
- -- multiple-repeater implementations) the rptrInfoTable should
- -- be implemented. It is the preferred source of this information,
- -- as it contains the values for all repeaters managed by the
- -- agent. In all cases, the objects in the rptrRptrInfo subtree
- -- are duplicates of the corresponding objects in the first entry
- -- of the rptrInfoTable.
-
- rptrGroupCapacity OBJECT-TYPE
- SYNTAX Integer32 (1..2147483647)
- MAX-ACCESS read-only
- STATUS deprecated
- DESCRIPTION
- "********* THIS OBJECT IS DEPRECATED **********
-
- The rptrGroupCapacity is the number of groups
- that can be contained within the repeater. Within
- each managed repeater, the groups are uniquely
- numbered in the range from 1 to rptrGroupCapacity.
-
- Some groups may not be present in the repeater, in
- which case the actual number of groups present
- will be less than rptrGroupCapacity. The number
- of groups present will never be greater than
- rptrGroupCapacity.
-
- Note: In practice, this will generally be the
- number of field-replaceable units (i.e., modules,
- cards, or boards) that can fit in the physical
- repeater enclosure, and the group numbers will
- correspond to numbers marked on the physical
- enclosure."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.1.1.3,
- aRepeaterGroupCapacity."
- ::= { rptrRptrInfo 1 }
-
- rptrOperStatus OBJECT-TYPE
- SYNTAX INTEGER {
- other(1), -- undefined or unknown
- ok(2), -- no known failures
- rptrFailure(3), -- repeater-related failure
- groupFailure(4), -- group-related failure
- portFailure(5), -- port-related failure
- generalFailure(6) -- failure, unspecified type
-
-
-
- de Graaf, et. al. Standards Track [Page 10]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- }
- MAX-ACCESS read-only
- STATUS deprecated
- DESCRIPTION
- "********* THIS OBJECT IS DEPRECATED **********
-
- The rptrOperStatus object indicates the
- operational state of the repeater. The
- rptrHealthText object may be consulted for more
- specific information about the state of the
- repeater's health.
-
- In the case of multiple kinds of failures (e.g.,
- repeater failure and port failure), the value of
- this attribute shall reflect the highest priority
- failure in the following order, listed highest
- priority first:
-
- rptrFailure(3)
- groupFailure(4)
- portFailure(5)
- generalFailure(6)."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.1.1.5, aRepeaterHealthState."
- ::= { rptrRptrInfo 2 }
-
- rptrHealthText OBJECT-TYPE
- SYNTAX DisplayString (SIZE (0..255))
- MAX-ACCESS read-only
- STATUS deprecated
- DESCRIPTION
- "********* THIS OBJECT IS DEPRECATED **********
-
- The health text object is a text string that
- provides information relevant to the operational
- state of the repeater. Agents may use this string
- to provide detailed information on current
- failures, including how they were detected, and/or
- instructions for problem resolution. The contents
- are agent-specific."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.1.1.6, aRepeaterHealthText."
- ::= { rptrRptrInfo 3 }
-
- rptrReset OBJECT-TYPE
- SYNTAX INTEGER {
- noReset(1),
- reset(2)
-
-
-
- de Graaf, et. al. Standards Track [Page 11]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- }
- MAX-ACCESS read-write
- STATUS deprecated
- DESCRIPTION
- "********* THIS OBJECT IS DEPRECATED **********
-
- Setting this object to reset(2) causes a
- transition to the START state of Fig 9-2 in
- section 9 [IEEE 802.3 Std] for a 10Mb/s repeater,
- and the START state of Fig 27-2 in section 27
- of that standard for a 100Mb/s repeater.
-
- Setting this object to noReset(1) has no effect.
- The agent will always return the value noReset(1)
- when this object is read.
-
- After receiving a request to set this variable to
- reset(2), the agent is allowed to delay the reset
- for a short period. For example, the implementor
- may choose to delay the reset long enough to allow
- the SNMP response to be transmitted. In any
- event, the SNMP response must be transmitted.
-
- This action does not reset the management counters
- defined in this document nor does it affect the
- portAdminStatus parameters. Included in this
- action is the execution of a disruptive Self-Test
- with the following characteristics: a) The nature
- of the tests is not specified. b) The test resets
- the repeater but without affecting management
- information about the repeater. c) The test does
- not inject packets onto any segment. d) Packets
- received during the test may or may not be
- transferred. e) The test does not interfere with
- management functions.
-
- After performing this self-test, the agent will
- update the repeater health information (including
- rptrOperStatus and rptrHealthText), and send a
- rptrHealth trap."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.1.2.1, acResetRepeater."
- ::= { rptrRptrInfo 4 }
-
- rptrNonDisruptTest OBJECT-TYPE
- SYNTAX INTEGER {
- noSelfTest(1),
- selfTest(2)
-
-
-
- de Graaf, et. al. Standards Track [Page 12]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- }
- MAX-ACCESS read-write
- STATUS deprecated
- DESCRIPTION
- "********* THIS OBJECT IS DEPRECATED **********
-
- Setting this object to selfTest(2) causes the
- repeater to perform a agent-specific, non-
- disruptive self-test that has the following
- characteristics: a) The nature of the tests is
- not specified. b) The test does not change the
- state of the repeater or management information
- about the repeater. c) The test does not inject
- packets onto any segment. d) The test does not
- prevent the relay of any packets. e) The test
- does not interfere with management functions.
-
- After performing this test, the agent will update
- the repeater health information (including
- rptrOperStatus and rptrHealthText) and send a
- rptrHealth trap.
-
- Note that this definition allows returning an
- 'okay' result after doing a trivial test.
-
- Setting this object to noSelfTest(1) has no
- effect. The agent will always return the value
- noSelfTest(1) when this object is read."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.1.2.2,
- acExecuteNonDisruptiveSelfTest."
- ::= { rptrRptrInfo 5 }
-
- rptrTotalPartitionedPorts OBJECT-TYPE
- SYNTAX Gauge32
- MAX-ACCESS read-only
- STATUS deprecated
- DESCRIPTION
- "********* THIS OBJECT IS DEPRECATED **********
-
- This object returns the total number of ports in
- the repeater whose current state meets all three
- of the following criteria: rptrPortOperStatus
- does not have the value notPresent(3),
- rptrPortAdminStatus is enabled(1), and
- rptrPortAutoPartitionState is autoPartitioned(2)."
- ::= { rptrRptrInfo 6 }
-
-
-
-
- de Graaf, et. al. Standards Track [Page 13]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- -- Basic information at the group level.
- --
- -- Configuration and status objects for each
- -- managed group in the system, independent
- -- of whether there is one or more managed
- -- repeater-units in the system.
-
- rptrGroupTable OBJECT-TYPE
- SYNTAX SEQUENCE OF RptrGroupEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Table of descriptive and status information about
- the groups of ports."
- ::= { rptrGroupInfo 1 }
-
- rptrGroupEntry OBJECT-TYPE
- SYNTAX RptrGroupEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "An entry in the table, containing information
- about a single group of ports."
- INDEX { rptrGroupIndex }
- ::= { rptrGroupTable 1 }
-
- RptrGroupEntry ::=
- SEQUENCE {
- rptrGroupIndex
- Integer32,
- rptrGroupDescr
- DisplayString,
- rptrGroupObjectID
- OBJECT IDENTIFIER,
- rptrGroupOperStatus
- INTEGER,
- rptrGroupLastOperStatusChange
- TimeTicks,
- rptrGroupPortCapacity
- Integer32
- }
-
- rptrGroupIndex OBJECT-TYPE
- SYNTAX Integer32 (1..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This object identifies the group within the
-
-
-
- de Graaf, et. al. Standards Track [Page 14]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- system for which this entry contains
- information."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.2.1.1, aGroupID."
- ::= { rptrGroupEntry 1 }
-
- rptrGroupDescr OBJECT-TYPE
- SYNTAX DisplayString (SIZE (0..255))
- MAX-ACCESS read-only
- STATUS deprecated
- DESCRIPTION
- "********* THIS OBJECT IS DEPRECATED **********
-
- A textual description of the group. This value
- should include the full name and version
- identification of the group's hardware type and
- indicate how the group is differentiated from
- other types of groups in the repeater. Plug-in
- Module, Rev A' or 'Barney Rubble 10BASE-T 4-port
- SIMM socket Version 2.1' are examples of valid
- group descriptions.
-
- It is mandatory that this only contain printable
- ASCII characters."
- ::= { rptrGroupEntry 2 }
-
- rptrGroupObjectID OBJECT-TYPE
- SYNTAX OBJECT IDENTIFIER
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The vendor's authoritative identification of the
- group. This value may be allocated within the SMI
- enterprises subtree (1.3.6.1.4.1) and provides a
- straight-forward and unambiguous means for
- determining what kind of group is being managed.
-
- For example, this object could take the value
- 1.3.6.1.4.1.4242.1.2.14 if vendor 'Flintstones,
- Inc.' was assigned the subtree 1.3.6.1.4.1.4242,
- and had assigned the identifier
- 1.3.6.1.4.1.4242.1.2.14 to its 'Wilma Flintstone
- 6-Port FOIRL Plug-in Module.'"
- ::= { rptrGroupEntry 3 }
-
- rptrGroupOperStatus OBJECT-TYPE
- SYNTAX INTEGER {
- other(1),
-
-
-
- de Graaf, et. al. Standards Track [Page 15]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- operational(2),
- malfunctioning(3),
- notPresent(4),
- underTest(5),
- resetInProgress(6)
- }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "An object that indicates the operational status
- of the group.
-
- A status of notPresent(4) indicates that the group
- is temporarily or permanently physically and/or
- logically not a part of the repeater. It is an
- implementation-specific matter as to whether the
- agent effectively removes notPresent entries from
- the table.
-
- A status of operational(2) indicates that the
- group is functioning, and a status of
- malfunctioning(3) indicates that the group is
- malfunctioning in some way."
- ::= { rptrGroupEntry 4 }
-
- rptrGroupLastOperStatusChange OBJECT-TYPE
- SYNTAX TimeTicks
- MAX-ACCESS read-only
- STATUS deprecated
- DESCRIPTION
- "********* THIS OBJECT IS DEPRECATED **********
-
- An object that contains the value of sysUpTime at
- the time when the last of the following occurred:
- 1) the agent cold- or warm-started;
- 2) the row for the group was created (such
- as when the group was added to the system); or
- 3) the value of rptrGroupOperStatus for the
- group changed.
-
- A value of zero indicates that the group's
- operational status has not changed since the agent
- last restarted."
- ::= { rptrGroupEntry 5 }
-
- rptrGroupPortCapacity OBJECT-TYPE
- SYNTAX Integer32 (1..2147483647)
- MAX-ACCESS read-only
-
-
-
- de Graaf, et. al. Standards Track [Page 16]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- STATUS current
- DESCRIPTION
- "The rptrGroupPortCapacity is the number of ports
- that can be contained within the group. Valid
- range is 1-2147483647. Within each group, the
- ports are uniquely numbered in the range from 1 to
- rptrGroupPortCapacity.
-
- Some ports may not be present in the system, in
- which case the actual number of ports present
- will be less than the value of rptrGroupPortCapacity.
- The number of ports present in the group will never
- be greater than the value of rptrGroupPortCapacity.
-
- Note: In practice, this will generally be the
- number of ports on a module, card, or board, and
- the port numbers will correspond to numbers marked
- on the physical embodiment."
- REFERENCE
- "IEEE 802.3 Mgt, 30.4.2.1.2, aGroupPortCapacity."
- ::= { rptrGroupEntry 6 }
-
-
- -- Basic information at the port level.
- --
- -- Configuration and status objects for
- -- each managed repeater port in the system,
- -- independent of whether there is one or more
- -- managed repeater-units in the system.
-
- rptrPortTable OBJECT-TYPE
- SYNTAX SEQUENCE OF RptrPortEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Table of descriptive and status information about
- the repeater ports in the system. The number of
- entries is independent of the number of repeaters
- in the managed system."
- ::= { rptrPortInfo 1 }
-
- rptrPortEntry OBJECT-TYPE
- SYNTAX RptrPortEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "An entry in the table, containing information
- about a single port."
-
-
-
- de Graaf, et. al. Standards Track [Page 17]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- INDEX { rptrPortGroupIndex, rptrPortIndex }
- ::= { rptrPortTable 1 }
-
- RptrPortEntry ::=
- SEQUENCE {
- rptrPortGroupIndex
- Integer32,
- rptrPortIndex
- Integer32,
- rptrPortAdminStatus
- INTEGER,
- rptrPortAutoPartitionState
- INTEGER,
- rptrPortOperStatus
- INTEGER,
- rptrPortRptrId
- Integer32
- }
-
- rptrPortGroupIndex OBJECT-TYPE
- SYNTAX Integer32 (1..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This object identifies the group containing the
- port for which this entry contains information."
- ::= { rptrPortEntry 1 }
-
- rptrPortIndex OBJECT-TYPE
- SYNTAX Integer32 (1..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This object identifies the port within the group
- for which this entry contains information. This
- identifies the port independently from the repeater
- it may be attached to. The numbering scheme for
- ports is implementation specific; however, this
- value can never be greater than
- rptrGroupPortCapacity for the associated group."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.1, aPortID."
- ::= { rptrPortEntry 2 }
-
- rptrPortAdminStatus OBJECT-TYPE
- SYNTAX INTEGER {
- enabled(1),
- disabled(2)
-
-
-
- de Graaf, et. al. Standards Track [Page 18]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- }
- MAX-ACCESS read-write
- STATUS current
- DESCRIPTION
- "Setting this object to disabled(2) disables the
- port. A disabled port neither transmits nor
- receives. Once disabled, a port must be
- explicitly enabled to restore operation. A port
- which is disabled when power is lost or when a
- reset is exerted shall remain disabled when normal
- operation resumes.
-
- The admin status takes precedence over auto-
- partition and functionally operates between the
- auto-partition mechanism and the AUI/PMA.
-
- Setting this object to enabled(1) enables the port
- and exerts a BEGIN on the port's auto-partition
- state machine.
-
- (In effect, when a port is disabled, the value of
- rptrPortAutoPartitionState for that port is frozen
- until the port is next enabled. When the port
- becomes enabled, the rptrPortAutoPartitionState
- becomes notAutoPartitioned(1), regardless of its
- pre-disabling state.)"
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.2, aPortAdminState
- and 30.4.3.2.1, acPortAdminControl."
- ::= { rptrPortEntry 3 }
-
- rptrPortAutoPartitionState OBJECT-TYPE
- SYNTAX INTEGER {
- notAutoPartitioned(1),
- autoPartitioned(2)
- }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The autoPartitionState flag indicates whether the
- port is currently partitioned by the repeater's
- auto-partition protection.
-
- The conditions that cause port partitioning are
- specified in partition state machine in Sections
- 9 and 27 of [IEEE 802.3 Std]. They are not
- differentiated here."
- REFERENCE
-
-
-
- de Graaf, et. al. Standards Track [Page 19]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- "[IEEE 802.3 Mgt], 30.4.3.1.3, aAutoPartitionState."
- ::= { rptrPortEntry 4 }
-
- rptrPortOperStatus OBJECT-TYPE
- SYNTAX INTEGER {
- operational(1),
- notOperational(2),
- notPresent(3)
- }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This object indicates the port's operational
- status. The notPresent(3) status indicates the
- port is physically removed (note this may or may
- not be possible depending on the type of port.)
- The operational(1) status indicates that the port
- is enabled (see rptrPortAdminStatus) and working,
- even though it might be auto-partitioned (see
- rptrPortAutoPartitionState).
-
- If this object has the value operational(1) and
- rptrPortAdminStatus is set to disabled(2), it is
- expected that this object's value will soon change
- to notOperational(2)."
- ::= { rptrPortEntry 5 }
-
- rptrPortRptrId OBJECT-TYPE
- SYNTAX Integer32 (0..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This object identifies the repeater to
- which this port belongs. The repeater
- identified by a particular value of this object
- is the same as that identified by the same
- value of rptrInfoId. A value of zero
- indicates that this port currently is not
- a member of any repeater."
- ::= { rptrPortEntry 6 }
-
-
- -- New version of basic information at the repeater level.
- --
- -- Configuration, status, and control objects for
- -- each managed repeater in the system.
-
- rptrInfoTable OBJECT-TYPE
-
-
-
- de Graaf, et. al. Standards Track [Page 20]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- SYNTAX SEQUENCE OF RptrInfoEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "A table of information about each
- non-trivial repeater. The number of entries
- depends on the physical configuration of the
- managed system."
- ::= { rptrAllRptrInfo 1 }
-
- rptrInfoEntry OBJECT-TYPE
- SYNTAX RptrInfoEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "An entry in the table, containing information
- about a single non-trivial repeater."
- INDEX { rptrInfoId }
- ::= { rptrInfoTable 1 }
-
- RptrInfoEntry ::=
- SEQUENCE {
- rptrInfoId
- Integer32,
- rptrInfoRptrType
- INTEGER,
- rptrInfoOperStatus
- INTEGER,
- rptrInfoReset
- INTEGER,
- rptrInfoPartitionedPorts
- Gauge32,
- rptrInfoLastChange
- TimeStamp
- }
-
- rptrInfoId OBJECT-TYPE
- SYNTAX Integer32 (1..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This object identifies the repeater for which
- this entry contains information."
- ::= { rptrInfoEntry 1 }
-
- rptrInfoRptrType OBJECT-TYPE
- SYNTAX INTEGER {
- other(1), -- undefined or unknown
-
-
-
- de Graaf, et. al. Standards Track [Page 21]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- tenMb(2),
- onehundredMbClassI(3),
- onehundredMbClassII(4)
- }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The rptrInfoRptrType returns a value that identifies
- the CSMA/CD repeater type."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.1.1.2, aRepeaterType."
- ::= { rptrInfoEntry 2 }
-
- rptrInfoOperStatus OBJECT-TYPE
- SYNTAX INTEGER {
- other(1),
- ok(2),
- failure(3)
- }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The rptrInfoOperStatus object indicates the
- operational state of the repeater."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.1.1.5, aRepeaterHealthState."
- ::= { rptrInfoEntry 3 }
-
- rptrInfoReset OBJECT-TYPE
- SYNTAX INTEGER {
- noReset(1),
- reset(2)
- }
- MAX-ACCESS read-write
- STATUS current
- DESCRIPTION
- "Setting this object to reset(2) causes a
- transition to the START state of Fig 9-2 in
- section 9 [IEEE 802.3 Std] for a 10Mb/s repeater,
- and to the START state of Fig 27-2 in section 27
- of that standard for a 100Mb/s repeater.
-
- Setting this object to noReset(1) has no effect.
- The agent will always return the value noReset(1)
- when this object is read.
-
- After receiving a request to set this variable to
- reset(2), the agent is allowed to delay the reset
-
-
-
- de Graaf, et. al. Standards Track [Page 22]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- for a short period. For example, the implementor
- may choose to delay the reset long enough to allow
- the SNMP response to be transmitted. In any
- event, the SNMP response must be transmitted.
-
- This action does not reset the management counters
- defined in this document nor does it affect the
- portAdminStatus parameters. Included in this
- action is the execution of a disruptive Self-Test
- with the following characteristics: a) The nature
- of the tests is not specified. b) The test resets
- the repeater but without affecting management
- information about the repeater. c) The test does
- not inject packets onto any segment. d) Packets
- received during the test may or may not be
- transferred. e) The test does not interfere with
- management functions.
-
- After performing this self-test, the agent will
- update the repeater health information (including
- rptrInfoOperStatus), and send a rptrInfoResetEvent
- notification."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.1.2.1, acResetRepeater."
- ::= { rptrInfoEntry 4 }
-
- rptrInfoPartitionedPorts OBJECT-TYPE
- SYNTAX Gauge32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This object returns the total number of ports in
- the repeater whose current state meets all three
- of the following criteria: rptrPortOperStatus
- does not have the value notPresent(3),
- rptrPortAdminStatus is enabled(1), and
- rptrPortAutoPartitionState is autoPartitioned(2)."
- ::= { rptrInfoEntry 5 }
-
- rptrInfoLastChange OBJECT-TYPE
- SYNTAX TimeStamp
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The value of sysUpTime when any of the following
- conditions occurred:
- 1) agent cold- or warm-started;
- 2) this instance of repeater was created
-
-
-
- de Graaf, et. al. Standards Track [Page 23]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- (such as when a device or module was
- added to the system);
- 3) a change in the value of rptrInfoOperStatus;
- 4) ports were added or removed as members of
- the repeater; or
- 5) any of the counters associated with this
- repeater had a discontinuity."
- ::= { rptrInfoEntry 6 }
-
-
-
-
- --
- -- Old version of statistics at the repeater level.
- --
- -- Performance monitoring statistics for the repeater
- --
- -- In a system containing a single managed repeater-unit,
- -- the statistics object for the repeater-unit.
-
- -- The objects contained under the rptrMonitorRptrInfo subtree are
- -- intended for backwards compatibility with implementations of
- -- RFC 1516 [11]. In newer implementations (both single- and
- -- multiple-repeater implementations), the rptrMonitorTable will
- -- be implemented. It is the preferred source of this information,
- -- as it contains the values for all repeaters managed by the
- -- agent. In all cases, the objects in the rptrMonitorRptrInfo
- -- subtree are duplicates of the corresponding objects in the
- -- first entry of the rptrMonitorTable.
-
-
- rptrMonitorTransmitCollisions OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS deprecated
- DESCRIPTION
- "********* THIS OBJECT IS DEPRECATED **********
-
- For a clause 9 (10Mb/s) repeater, this counter
- is incremented every time the repeater state
- machine enters the TRANSMIT COLLISION state
- from any state other than ONE PORT LEFT
- (Ref: Fig 9-2 [IEEE 802.3 Std]).
-
- For a clause 27 repeater, this counter is
- incremented every time the repeater core state
- diagram enters the Jam state as a result of
- Activity(ALL) > 1 (fig 27-2 [IEEE 802.3 Std]).
-
-
-
- de Graaf, et. al. Standards Track [Page 24]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- The approximate minimum time for rollover of this
- counter is 16 hours in a 10Mb/s repeater and 1.6
- hours in a 100Mb/s repeater."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.1.1.8, aTransmitCollisions."
- ::= { rptrMonitorRptrInfo 1 }
-
-
- -- Statistics at the group level.
- --
- -- In a system containing a single managed repeater-unit,
- -- the statistics objects for each group.
-
- rptrMonitorGroupTable OBJECT-TYPE
- SYNTAX SEQUENCE OF RptrMonitorGroupEntry
- MAX-ACCESS not-accessible
- STATUS deprecated
- DESCRIPTION
- "********* THIS OBJECT IS DEPRECATED **********
-
- Table of performance and error statistics for the
- groups within the repeater. The number of entries
- is the same as that in the rptrGroupTable."
- ::= { rptrMonitorGroupInfo 1 }
-
- rptrMonitorGroupEntry OBJECT-TYPE
- SYNTAX RptrMonitorGroupEntry
- MAX-ACCESS not-accessible
- STATUS deprecated
- DESCRIPTION
- "********* THIS OBJECT IS DEPRECATED **********
-
- An entry in the table, containing total
- performance and error statistics for a single
- group. Regular retrieval of the information in
- this table provides a means of tracking the
- performance and health of the networked devices
- attached to this group's ports.
-
- The counters in this table are redundant in the
- sense that they are the summations of information
- already available through other objects. However,
- these sums provide a considerable optimization of
- network management traffic over the otherwise
- necessary retrieval of the individual counters
- included in each sum.
-
- Note: Group-level counters are
-
-
-
- de Graaf, et. al. Standards Track [Page 25]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- deprecated in this MIB. It is recommended
- that management applications instead use
- the repeater-level counters contained in
- the rptrMonTable."
- INDEX { rptrMonitorGroupIndex }
- ::= { rptrMonitorGroupTable 1 }
-
- RptrMonitorGroupEntry ::=
- SEQUENCE {
- rptrMonitorGroupIndex
- Integer32,
- rptrMonitorGroupTotalFrames
- Counter32,
- rptrMonitorGroupTotalOctets
- Counter32,
- rptrMonitorGroupTotalErrors
- Counter32
- }
-
- rptrMonitorGroupIndex OBJECT-TYPE
- SYNTAX Integer32 (1..2147483647)
- MAX-ACCESS read-only
- STATUS deprecated
- DESCRIPTION
- "********* THIS OBJECT IS DEPRECATED **********
-
- This object identifies the group within the
- repeater for which this entry contains
- information."
- ::= { rptrMonitorGroupEntry 1 }
-
- rptrMonitorGroupTotalFrames OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS deprecated
- DESCRIPTION
- "********* THIS OBJECT IS DEPRECATED **********
-
- The total number of frames of valid frame length
- that have been received on the ports in this group
- and for which the FCSError and CollisionEvent
- signals were not asserted. This counter is the
- summation of the values of the
- rptrMonitorPortReadableFrames counters for all of
- the ports in the group.
-
- This statistic provides one of the parameters
- necessary for obtaining the packet error rate.
-
-
-
- de Graaf, et. al. Standards Track [Page 26]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- The approximate minimum time for rollover of this
- counter is 80 hours in a 10Mb/s repeater."
- ::= { rptrMonitorGroupEntry 2 }
-
- rptrMonitorGroupTotalOctets OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS deprecated
- DESCRIPTION
- "********* THIS OBJECT IS DEPRECATED **********
-
- The total number of octets contained in the valid
- frames that have been received on the ports in
- this group. This counter is the summation of the
- values of the rptrMonitorPortReadableOctets
- counters for all of the ports in the group.
-
- This statistic provides an indicator of the total
- data transferred. The approximate minimum time
- for rollover of this counter is 58 minutes in a
- 10Mb/s repeater."
- ::= { rptrMonitorGroupEntry 3 }
-
- rptrMonitorGroupTotalErrors OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS deprecated
- DESCRIPTION
- "********* THIS OBJECT IS DEPRECATED **********
-
- The total number of errors which have occurred on
- all of the ports in this group. This counter is
- the summation of the values of the
- rptrMonitorPortTotalErrors counters for all of the
- ports in the group."
- ::= { rptrMonitorGroupEntry 4 }
-
-
- -- Statistics at the port level.
- --
-
- rptrMonitorPortTable OBJECT-TYPE
- SYNTAX SEQUENCE OF RptrMonitorPortEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Table of performance and error statistics for the
- ports. The number of entries is the same as that
-
-
-
- de Graaf, et. al. Standards Track [Page 27]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- in the rptrPortTable.
-
- The columnar object rptrMonitorPortLastChange
- is used to indicate possible discontinuities
- of counter type columnar objects in the table."
- ::= { rptrMonitorPortInfo 1 }
-
- rptrMonitorPortEntry OBJECT-TYPE
- SYNTAX RptrMonitorPortEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "An entry in the table, containing performance and
- error statistics for a single port."
- INDEX { rptrMonitorPortGroupIndex, rptrMonitorPortIndex }
- ::= { rptrMonitorPortTable 1 }
-
- RptrMonitorPortEntry ::=
- SEQUENCE {
- rptrMonitorPortGroupIndex
- Integer32,
- rptrMonitorPortIndex
- Integer32,
- rptrMonitorPortReadableFrames
- Counter32,
- rptrMonitorPortReadableOctets
- Counter32,
- rptrMonitorPortFCSErrors
- Counter32,
- rptrMonitorPortAlignmentErrors
- Counter32,
- rptrMonitorPortFrameTooLongs
- Counter32,
- rptrMonitorPortShortEvents
- Counter32,
- rptrMonitorPortRunts
- Counter32,
- rptrMonitorPortCollisions
- Counter32,
- rptrMonitorPortLateEvents
- Counter32,
- rptrMonitorPortVeryLongEvents
- Counter32,
- rptrMonitorPortDataRateMismatches
- Counter32,
- rptrMonitorPortAutoPartitions
- Counter32,
- rptrMonitorPortTotalErrors
-
-
-
- de Graaf, et. al. Standards Track [Page 28]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- Counter32,
- rptrMonitorPortLastChange
- TimeStamp
- }
-
- rptrMonitorPortGroupIndex OBJECT-TYPE
- SYNTAX Integer32 (1..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This object identifies the group containing the
- port for which this entry contains information."
- ::= { rptrMonitorPortEntry 1 }
-
- rptrMonitorPortIndex OBJECT-TYPE
- SYNTAX Integer32 (1..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This object identifies the port within the group
- for which this entry contains information."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.1, aPortID."
- ::= { rptrMonitorPortEntry 2 }
-
- rptrMonitorPortReadableFrames OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This object is the number of frames of valid
- frame length that have been received on this port.
- This counter is incremented by one for each frame
- received on this port whose OctetCount is greater
- than or equal to minFrameSize and less than or
- equal to maxFrameSize (Ref: IEEE 802.3 Std,
- 4.4.2.1) and for which the FCSError and
- CollisionEvent signals are not asserted.
-
- A discontinuity may occur in the value
- when the value of object
- rptrMonitorPortLastChange changes.
-
- This statistic provides one of the parameters
- necessary for obtaining the packet error rate.
- The approximate minimum time for rollover of this
- counter is 80 hours at 10Mb/s."
- REFERENCE
-
-
-
- de Graaf, et. al. Standards Track [Page 29]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- "[IEEE 802.3 Mgt], 30.4.3.1.4, aReadableFrames."
- ::= { rptrMonitorPortEntry 3 }
-
- rptrMonitorPortReadableOctets OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This object is the number of octets contained in
- valid frames that have been received on this port.
- This counter is incremented by OctetCount for each
- frame received on this port which has been
- determined to be a readable frame (i.e., including
- FCS octets but excluding framing bits and dribble
- bits).
-
- A discontinuity may occur in the value
- when the value of object
- rptrMonitorPortLastChange changes.
-
- This statistic provides an indicator of the total
- data transferred. The approximate minimum time
- for rollover of this counter in a 10Mb/s repeater
- is 58 minutes.
-
- For ports receiving traffic at a maximum rate in
- a 100Mb/s repeater, this counter can roll over
- in less than 6 minutes. Since that amount of time
- could be less than a management station's poll cycle
- time, in order to avoid a loss of information a
- management station is advised to also poll the
- rptrMonitorPortUpper32Octets object, or to use the
- 64-bit counter defined by
- rptrMonitorPortHCReadableOctets instead of the
- two 32-bit counters."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.5, aReadableOctets."
- ::= { rptrMonitorPortEntry 4 }
-
- rptrMonitorPortFCSErrors OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This counter is incremented by one for each frame
- received on this port with the FCSError signal
- asserted and the FramingError and CollisionEvent
- signals deasserted and whose OctetCount is greater
-
-
-
- de Graaf, et. al. Standards Track [Page 30]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- than or equal to minFrameSize and less than or
- equal to maxFrameSize (Ref: 4.4.2.1, IEEE 802.3
- Std).
-
- A discontinuity may occur in the value
- when the value of object
- rptrMonitorPortLastChange changes.
-
- The approximate minimum time for rollover of this
- counter is 80 hours at 10Mb/s."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.6,
- aFrameCheckSequenceErrors."
- ::= { rptrMonitorPortEntry 5 }
-
- rptrMonitorPortAlignmentErrors OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This counter is incremented by one for each frame
- received on this port with the FCSError and
- FramingError signals asserted and CollisionEvent
- signal deasserted and whose OctetCount is greater
- than or equal to minFrameSize and less than or
- equal to maxFrameSize (Ref: IEEE 802.3 Std,
- 4.4.2.1). If rptrMonitorPortAlignmentErrors is
- incremented then the rptrMonitorPortFCSErrors
- Counter shall not be incremented for the same
- frame.
-
- A discontinuity may occur in the value
- when the value of object
- rptrMonitorPortLastChange changes.
-
- The approximate minimum time for rollover of this
- counter is 80 hours at 10Mb/s."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.7, aAlignmentErrors."
- ::= { rptrMonitorPortEntry 6 }
-
- rptrMonitorPortFrameTooLongs OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This counter is incremented by one for each frame
- received on this port whose OctetCount is greater
-
-
-
- de Graaf, et. al. Standards Track [Page 31]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- than maxFrameSize (Ref: 4.4.2.1, IEEE 802.3 Std).
- If rptrMonitorPortFrameTooLongs is incremented
- then neither the rptrMonitorPortAlignmentErrors
- nor the rptrMonitorPortFCSErrors counter shall be
- incremented for the frame.
-
- A discontinuity may occur in the value
- when the value of object
- rptrMonitorPortLastChange changes.
-
- The approximate minimum time for rollover of this
- counter is 61 days in a 10Mb/s repeater."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.8, aFramesTooLong."
- ::= { rptrMonitorPortEntry 7 }
-
- rptrMonitorPortShortEvents OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This counter is incremented by one for each
- CarrierEvent on this port with ActivityDuration
- less than ShortEventMaxTime. ShortEventMaxTime is
- greater than 74 bit times and less than 82 bit
- times. ShortEventMaxTime has tolerances included
- to provide for circuit losses between a
- conformance test point at the AUI and the
- measurement point within the state machine.
-
- Notes:
-
- ShortEvents may indicate externally
- generated noise hits which will cause the repeater
- to transmit Runts to its other ports, or propagate
- a collision (which may be late) back to the
- transmitting DTE and damaged frames to the rest of
- the network.
-
- Implementors may wish to consider selecting the
- ShortEventMaxTime towards the lower end of the
- allowed tolerance range to accommodate bit losses
- suffered through physical channel devices not
- budgeted for within this standard.
-
- The significance of this attribute is different
- in 10 and 100 Mb/s collision domains. Clause 9
- repeaters perform fragment extension of short
-
-
-
- de Graaf, et. al. Standards Track [Page 32]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- events which would be counted as runts on the
- interconnect ports of other repeaters. Clause
- 27 repeaters do not perform fragment extension.
-
- A discontinuity may occur in the value
- when the value of object
- rptrMonitorPortLastChange changes.
-
- The approximate minimum time for rollover of this
- counter is 16 hours in a 10Mb/s repeater."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.9, aShortEvents."
- ::= { rptrMonitorPortEntry 8 }
-
- rptrMonitorPortRunts OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This counter is incremented by one for each
- CarrierEvent on this port that meets one of the
- following two conditions. Only one test need be
- made. a) The ActivityDuration is greater than
- ShortEventMaxTime and less than ValidPacketMinTime
- and the CollisionEvent signal is deasserted. b)
- The OctetCount is less than 64, the
- ActivityDuration is greater than ShortEventMaxTime
- and the CollisionEvent signal is deasserted.
- ValidPacketMinTime is greater than or equal to 552
- bit times and less than 565 bit times.
-
- An event whose length is greater than 74 bit times
- but less than 82 bit times shall increment either
- the shortEvents counter or the runts counter but
- not both. A CarrierEvent greater than or equal to
- 552 bit times but less than 565 bit times may or
- may not be counted as a runt.
-
- ValidPacketMinTime has tolerances included to
- provide for circuit losses between a conformance
- test point at the AUI and the measurement point
- within the state machine.
-
- Runts usually indicate collision fragments, a
- normal network event. In certain situations
- associated with large diameter networks a
- percentage of collision fragments may exceed
- ValidPacketMinTime.
-
-
-
- de Graaf, et. al. Standards Track [Page 33]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- A discontinuity may occur in the value
- when the value of object
- rptrMonitorPortLastChange changes.
-
- The approximate minimum time for rollover of this
- counter is 16 hours in a 10Mb/s repeater."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.10, aRunts."
- ::= { rptrMonitorPortEntry 9 }
-
- rptrMonitorPortCollisions OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "For a clause 9 repeater, this counter is
- incremented by one for any CarrierEvent signal
- on any port for which the CollisionEvent signal
- on this port is asserted. For a clause 27
- repeater port the counter increments on entering
- the Collision Count Increment state of the
- partition state diagram (fig 27-8 of
- [IEEE 802.3 Std]).
-
- A discontinuity may occur in the value
- when the value of object
- rptrMonitorPortLastChange changes.
-
- The approximate minimum time for rollover of this
- counter is 16 hours in a 10Mb/s repeater."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.11, aCollisions."
- ::= { rptrMonitorPortEntry 10 }
-
- rptrMonitorPortLateEvents OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "For a clause 9 repeater port, this counter is
- incremented by one for each CarrierEvent
- on this port in which the CollIn(X)
- variable transitions to the value SQE (Ref:
- 9.6.6.2, IEEE 802.3 Std) while the
- ActivityDuration is greater than the
- LateEventThreshold. For a clause 27 repeater
- port, this counter is incremented by one on
- entering the Collision Count Increment state
-
-
-
- de Graaf, et. al. Standards Track [Page 34]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- of the partition state diagram (fig 27-8)
- while the ActivityDuration is greater than
- the LateEvent- Threshold. Such a CarrierEvent
- is counted twice, as both a collision and as a
- lateEvent.
-
- The LateEventThreshold is greater than 480 bit
- times and less than 565 bit times.
- LateEventThreshold has tolerances included to
- permit an implementation to build a single
- threshold to serve as both the LateEventThreshold
- and ValidPacketMinTime threshold.
-
- A discontinuity may occur in the value
- when the value of object
- rptrMonitorPortLastChange changes.
-
- The approximate minimum time for rollover of this
- counter is 81 hours in a 10Mb/s repeater."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.12, aLateEvents."
- ::= { rptrMonitorPortEntry 11 }
-
- rptrMonitorPortVeryLongEvents OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "For a clause 9 repeater port, this counter
- is incremented by one for each CarrierEvent
- whose ActivityDuration is greater than the
- MAU Jabber Lockup Protection timer TW3
- (Ref: 9.6.1 & 9.6.5, IEEE 802.3 Std).
-
- For a clause 27 repeater port, this counter
- is incremented by one on entry to the
- Rx Jabber state of the receiver timer state
- diagram (fig 27-7). Other counters may
- be incremented as appropriate.
-
- A discontinuity may occur in the value
- when the value of object
- rptrMonitorPortLastChange changes."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.13, aVeryLongEvents."
- ::= { rptrMonitorPortEntry 12 }
-
- rptrMonitorPortDataRateMismatches OBJECT-TYPE
-
-
-
- de Graaf, et. al. Standards Track [Page 35]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This counter is incremented by one for each
- frame received by this port that meets all
- of the conditions required by only one of the
- following two measurement methods:
-
- Measurement method A: 1) The CollisionEvent
- signal is not asserted (10Mb/s operation) or
- the Collision Count Increment state of the
- partition state diagram (fig 27-8 of
- [IEEE 802.3 Std]) has not been entered
- (100Mb/s operation). 2) The ActivityDuration
- is greater than ValidPacketMinTime. 3) The
- frequency (data rate) is detectably mismatched
- from the local transmit frequency.
-
- Measurement method B: 1) The CollisionEvent
- signal is not asserted (10Mb/s operation)
- or the Collision Count Increment state of the
- partition state diagram (fig 27-8 of
- [IEEE 802.3 Std]) has not been entered
- (100Mb/s operation). 2) The OctetCount is
- greater than 63. 3) The frequency (data
- rate) is detectably mismatched from the local
- transmit frequency. The exact degree of
- mismatch is vendor specific and is to be
- defined by the vendor for conformance testing.
-
- When this event occurs, other counters whose
- increment conditions were satisfied may or may not
- also be incremented, at the implementor's
- discretion. Whether or not the repeater was able
- to maintain data integrity is beyond the scope of
- this standard.
-
- A discontinuity may occur in the value
- when the value of object
- rptrMonitorPortLastChange changes."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.14, aDataRateMismatches."
- ::= { rptrMonitorPortEntry 13 }
-
- rptrMonitorPortAutoPartitions OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
-
-
-
- de Graaf, et. al. Standards Track [Page 36]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- STATUS current
- DESCRIPTION
- "This counter is incremented by one for
- each time the repeater has automatically
- partitioned this port.
-
- The conditions that cause a clause 9
- repeater port to partition are specified in
- the partition state diagram in clause 9 of
- [IEEE 802.3 Std]. They are not differentiated
- here. A clause 27 repeater port partitions
- on entry to the Partition Wait state of the
- partition state diagram (fig 27-8 in
- [IEEE 802.3 Std]).
-
- A discontinuity may occur in the value
- when the value of object
- rptrMonitorPortLastChange changes."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.15, aAutoPartitions."
- ::= { rptrMonitorPortEntry 14 }
-
- rptrMonitorPortTotalErrors OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of errors which have occurred on
- this port. This counter is the summation of the
- values of other error counters (for the same
- port), namely:
-
- rptrMonitorPortFCSErrors,
- rptrMonitorPortAlignmentErrors,
- rptrMonitorPortFrameTooLongs,
- rptrMonitorPortShortEvents,
- rptrMonitorPortLateEvents,
- rptrMonitorPortVeryLongEvents,
- rptrMonitorPortDataRateMismatches, and
- rptrMonitorPortSymbolErrors.
-
- This counter is redundant in the sense that it is
- the summation of information already available
- through other objects. However, it is included
- specifically because the regular retrieval of this
- object as a means of tracking the health of a port
- provides a considerable optimization of network
- management traffic over the otherwise necessary
-
-
-
- de Graaf, et. al. Standards Track [Page 37]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- retrieval of the summed counters.
-
- Note that rptrMonitorPortRunts is not included
- in this total; this is because runts usually
- indicate collision fragments, a normal network
- event.
-
- A discontinuity may occur in the value
- when the value of object
- rptrMonitorPortLastChange changes."
- ::= { rptrMonitorPortEntry 15 }
-
- rptrMonitorPortLastChange OBJECT-TYPE
- SYNTAX TimeStamp
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The value of sysUpTime when the last of
- the following occurred:
- 1) the agent cold- or warm-started;
- 2) the row for the port was created
- (such as when a device or module was added
- to the system); or
- 3) any condition that would cause one of
- the counters for the row to experience
- a discontinuity."
- ::= { rptrMonitorPortEntry 16 }
-
- rptrMonitor100PortTable OBJECT-TYPE
- SYNTAX SEQUENCE OF RptrMonitor100PortEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Table of additional performance and error
- statistics for 100Mb/s ports, above and
- beyond those parameters that apply to both
- 10 and 100Mbps ports. Entries exist only for
- ports attached to 100Mbps repeaters.
-
- The columnar object rptrMonitorPortLastChange
- is used to indicate possible discontinuities
- of counter type columnar objects in this table."
- ::= { rptrMonitorPortInfo 2 }
-
- rptrMonitor100PortEntry OBJECT-TYPE
- SYNTAX RptrMonitor100PortEntry
- MAX-ACCESS not-accessible
- STATUS current
-
-
-
- de Graaf, et. al. Standards Track [Page 38]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- DESCRIPTION
- "An entry in the table, containing performance
- and error statistics for a single 100Mb/s port."
- INDEX { rptrMonitorPortGroupIndex, rptrMonitorPortIndex }
- ::= { rptrMonitor100PortTable 1 }
-
- RptrMonitor100PortEntry ::=
- SEQUENCE {
- rptrMonitorPortIsolates
- Counter32,
- rptrMonitorPortSymbolErrors
- Counter32,
- rptrMonitorPortUpper32Octets
- Counter32,
- rptrMonitorPortHCReadableOctets
- Counter64
- }
-
- rptrMonitorPortIsolates OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This counter is incremented by one each time that
- the repeater port automatically isolates as a
- consequence of false carrier events. The conditions
- which cause a port to automatically isolate are
- defined by the transition from the False Carrier
- state to the Link Unstable state of the carrier
- integrity state diagram (figure 27-9)
- [IEEE 802.3 Standard].
-
- Note: Isolates do not affect the value of
- the PortOperStatus object.
-
- A discontinuity may occur in the value
- when the value of object
- rptrMonitorPortLastChange changes."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.16, aIsolates."
- ::= { rptrMonitor100PortEntry 1 }
-
- rptrMonitorPortSymbolErrors OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This counter is incremented by one each time when
-
-
-
- de Graaf, et. al. Standards Track [Page 39]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- valid length packet was received at the port and
- there was at least one occurrence of an invalid
- data symbol. This can increment only once per valid
- carrier event. A collision presence at any port of
- the repeater containing port N, will not cause this
- attribute to increment.
-
- A discontinuity may occur in the value
- when the value of object
- rptrMonitorPortLastChange changes.
-
- The approximate minimum time for rollover of this
- counter is 7.4 hours at 100Mb/s."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.17,
- aSymbolErrorDuringPacket."
- ::= { rptrMonitor100PortEntry 2 }
-
- rptrMonitorPortUpper32Octets OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This object is the number of octets contained in
- valid frames that have been received on this port,
- modulo 2**32. That is, it contains the upper 32
- bits of a 64-bit octets counter, of which the
- lower 32 bits are contained in the
- rptrMonitorPortReadableOctets object.
-
- This two-counter mechanism is provided for those
- network management protocols that do not support
- 64-bit counters (e.g. SNMP V1) and are used to
- manage a repeater type of 100Mb/s.
-
- Conformance clauses for this MIB are defined such
- that implementation of this object is not required
- in a system which does not support 100Mb/s.
- However, systems with mixed 10 and 100Mb/s ports
- may implement this object across all ports,
- including 10Mb/s. If this object is implemented,
- it must be according to the definition in the first
- paragraph of this description; that is, the value
- of this object MUST be a valid count.
-
- A discontinuity may occur in the value
- when the value of object
- rptrMonitorPortLastChange changes."
-
-
-
- de Graaf, et. al. Standards Track [Page 40]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- ::= { rptrMonitor100PortEntry 3 }
-
- rptrMonitorPortHCReadableOctets OBJECT-TYPE
- SYNTAX Counter64
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This object is the number of octets contained in
- valid frames that have been received on this port.
- This counter is incremented by OctetCount for each
- frame received on this port which has been
- determined to be a readable frame (i.e., including
- FCS octets but excluding framing bits and dribble
- bits).
-
- This statistic provides an indicator of the total
- data transferred.
-
- This counter is a 64-bit version of rptrMonitor-
- PortReadableOctets. It should be used by network
- management protocols which suppport 64-bit counters
- (e.g. SNMPv2).
-
- Conformance clauses for this MIB are defined such
- that implementation of this object is not required
- in a system which does not support 100Mb/s.
- However, systems with mixed 10 and 100Mb/s ports
- may implement this object across all ports,
- including 10Mb/s. If this object is implemented,
- it must be according to the definition in the first
- paragraph of this description; that is, the value
- of this object MUST be a valid count.
-
- A discontinuity may occur in the value
- when the value of object
- rptrMonitorPortLastChange changes."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.5, aReadableOctets."
- ::= { rptrMonitor100PortEntry 4 }
-
-
- -- New version of statistics at the repeater level.
- --
- -- Statistics objects for each managed repeater
- -- in the system.
-
- rptrMonTable OBJECT-TYPE
- SYNTAX SEQUENCE OF RptrMonEntry
-
-
-
- de Graaf, et. al. Standards Track [Page 41]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "A table of information about each
- non-trivial repeater. The number of entries
- in this table is the same as the number of
- entries in the rptrInfoTable.
-
- The columnar object rptrInfoLastChange is
- used to indicate possible discontinuities of
- counter type columnar objects in this table."
- ::= { rptrMonitorAllRptrInfo 1 }
-
- rptrMonEntry OBJECT-TYPE
- SYNTAX RptrMonEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "An entry in the table, containing information
- about a single non-trivial repeater."
- INDEX { rptrInfoId }
- ::= { rptrMonTable 1 }
-
- RptrMonEntry ::=
- SEQUENCE {
- rptrMonTxCollisions
- Counter32,
- rptrMonTotalFrames
- Counter32,
- rptrMonTotalErrors
- Counter32,
- rptrMonTotalOctets
- Counter32
- }
-
- rptrMonTxCollisions OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "For a clause 9 (10Mb/s) repeater, this counter
- is incremented every time the repeater state
- machine enters the TRANSMIT COLLISION state
- from any state other than ONE PORT LEFT
- (Ref: Fig 9-2 [IEEE 802.3 Std]).
-
- For a clause 27 repeater, this counter is
- incremented every time the repeater core state
-
-
-
- de Graaf, et. al. Standards Track [Page 42]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- diagram enters the Jam state as a result of
- Activity(ALL) > 1 (fig 27-2 [IEEE 802.3 Std]).
-
- The approximate minimum time for rollover of this
- counter is 16 hours in a 10Mb/s repeater and 1.6
- hours in a 100Mb/s repeater."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.1.1.8, aTransmitCollisions"
- ::= { rptrMonEntry 1 }
-
- rptrMonTotalFrames OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of frames of valid frame length
- that have been received on the ports in this repeater
- and for which the FCSError and CollisionEvent
- signals were not asserted. If an implementation
- can not obtain a count of frames as seen by
- the repeater itself, this counter may be
- implemented as the summation of the values of the
- rptrMonitorPortReadableFrames counters for all of
- the ports in the repeater.
-
- This statistic provides one of the parameters
- necessary for obtaining the packet error rate.
- The approximate minimum time for rollover of this
- counter is 80 hours in a 10Mb/s repeater."
- ::= { rptrMonEntry 3 }
-
- rptrMonTotalErrors OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of errors which have occurred on
- all of the ports in this repeater. The errors
- included in this count are the same as those listed
- for the rptrMonitorPortTotalErrors counter. If an
- implementation can not obtain a count of these
- errors as seen by the repeater itself, this counter
- may be implemented as the summation of the values of
- the rptrMonitorPortTotalErrors counters for all of
- the ports in the repeater."
- ::= { rptrMonEntry 4 }
-
- rptrMonTotalOctets OBJECT-TYPE
-
-
-
- de Graaf, et. al. Standards Track [Page 43]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of octets contained in the valid
- frames that have been received on the ports in
- this group. If an implementation can not obtain
- a count of octets as seen by the repeater itself,
- this counter may be the summation of the
- values of the rptrMonitorPortReadableOctets
- counters for all of the ports in the group.
-
- This statistic provides an indicator of the total
- data transferred. The approximate minimum time
- for rollover of this counter in a 10Mb/s repeater
- is 58 minutes divided by the number of ports in
- the repeater.
-
- For 100Mb/s repeaters processing traffic at a
- maximum rate, this counter can roll over in less
- than 6 minutes divided by the number of ports in
- the repeater. Since that amount of time could
- be less than a management station's poll cycle
- time, in order to avoid a loss of information a
- management station is advised to also poll the
- rptrMonUpper32TotalOctets object, or to use the
- 64-bit counter defined by rptrMonHCTotalOctets
- instead of the two 32-bit counters."
- ::= { rptrMonEntry 5 }
-
- rptrMon100Table OBJECT-TYPE
- SYNTAX SEQUENCE OF RptrMon100Entry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "A table of additional information about each
- 100Mb/s repeater, augmenting the entries in
- the rptrMonTable. Entries exist in this table
- only for 100Mb/s repeaters.
-
- The columnar object rptrInfoLastChange is
- used to indicate possible discontinuities of
- counter type columnar objects in this table."
- ::= { rptrMonitorAllRptrInfo 2 }
-
- rptrMon100Entry OBJECT-TYPE
- SYNTAX RptrMon100Entry
- MAX-ACCESS not-accessible
-
-
-
- de Graaf, et. al. Standards Track [Page 44]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- STATUS current
- DESCRIPTION
- "An entry in the table, containing information
- about a single 100Mbps repeater."
- INDEX { rptrInfoId }
- ::= { rptrMon100Table 1 }
-
- RptrMon100Entry ::=
- SEQUENCE {
- rptrMonUpper32TotalOctets
- Counter32,
- rptrMonHCTotalOctets
- Counter64
- }
-
- rptrMonUpper32TotalOctets OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of octets contained in the valid
- frames that have been received on the ports in
- this repeater, modulo 2**32. That is, it contains
- the upper 32 bits of a 64-bit counter, of which
- the lower 32 bits are contained in the
- rptrMonTotalOctets object. If an implementation
- can not obtain a count of octets as seen
- by the repeater itself, the 64-bit value
- may be the summation of the values of the
- rptrMonitorPortReadableOctets counters combined
- with the corresponding rptrMonitorPortUpper32Octets
- counters for all of the ports in the repeater.
-
- This statistic provides an indicator of the total
- data transferred within the repeater.
-
- This two-counter mechanism is provided for those
- network management protocols that do not support
- 64-bit counters (e.g. SNMP V1) and are used to
- manage a repeater type of 100Mb/s.
-
- Conformance clauses for this MIB are defined such
- that implementation of this object is not required
- in a system which does not support 100Mb/s.
- However, systems with mixed 10 and 100Mb/s ports
- may implement this object across all ports,
- including 10Mb/s. If this object is implemented,
- it must be according to the definition in the first
-
-
-
- de Graaf, et. al. Standards Track [Page 45]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- paragraph of this description; that is, the value
- of this object MUST be a valid count."
- ::= { rptrMon100Entry 1 }
-
- rptrMonHCTotalOctets OBJECT-TYPE
- SYNTAX Counter64
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The total number of octets contained in the valid
- frames that have been received on the ports in
- this group. If a implementation can not obtain
- a count of octets as seen by the repeater itself,
- this counter may be the summation of the
- values of the rptrMonitorPortReadableOctets
- counters for all of the ports in the group.
-
- This statistic provides an indicator of the total
- data transferred.
-
- This counter is a 64-bit (high-capacity) version
- of rptrMonUpper32TotalOctets and rptrMonTotalOctets.
- It should be used by network management protocols
- which support 64-bit counters (e.g. SNMPv2).
-
- Conformance clauses for this MIB are defined such
- that implementation of this object is not required
- in a system which does not support 100Mb/s.
- However, systems with mixed 10 and 100Mb/s ports
- may implement this object across all ports,
- including 10Mb/s. If this object is implemented,
- it must be according to the definition in the first
- paragraph of this description; that is, the value
- of this object MUST be a valid count."
- ::= { rptrMon100Entry 2 }
-
-
- --
- -- The Repeater Address Search Table
- --
- -- This table provides an active address tracking
- -- capability which can be also used to collect the
- -- necessary information for mapping the topology
- -- of a network. Note that an NMS is required to have
- -- read-write access to the table in order to access
- -- this function. Section 4, "Topology Mapping",
- -- contains a description of an algorithm which can
- -- make use of this table, in combination with the
-
-
-
- de Graaf, et. al. Standards Track [Page 46]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- -- forwarding databases of managed bridges/switches
- -- in the network, to map network topology.
- --
-
- rptrAddrSearchTable OBJECT-TYPE
- SYNTAX SEQUENCE OF RptrAddrSearchEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "This table contains one entry per repeater in the
- system. It defines objects which allow a network
- management application to instruct an agent to watch
- for a given MAC address and report which port it
- was seen on. Only one address search can be in
- progress on each repeater at any one time. Before
- starting an address search, a management application
- should obtain 'ownership' of the entry in
- rptrAddrSearchTable for the repeater that is to
- perform the search. This is accomplished with the
- rptrAddrSearchLock and rptrAddrSearchStatus as
- follows:
-
- try_again:
- get(rptrAddrSearchLock, rptrAddrSearchStatus)
- while (rptrAddrSearchStatus != notInUse)
- {
- /* Loop waiting for objects to be available*/
- short delay
- get(rptrAddrSearchLock, rptrAddrSearchStatus)
- }
-
- /* Try to claim map objects */
- lock_value = rptrAddrSearchLock
- if ( set(rptrAddrSearchLock = lock_value,
- rptrAddrSearchStatus = inUse,
- rptrAddrSearchOwner = 'my-IP-address)
- == FAILURE)
- /* Another manager got the lock */
- goto try_again
-
- /* I have the lock */
- set (rptrAddrSearchAddress = <search target>)
-
- wait for rptrAddrSearchState to change from none
-
- if (rptrAddrSearchState == single)
- get (rptrAddrSearchGroup, rptrAddrSearchPort)
-
-
-
-
- de Graaf, et. al. Standards Track [Page 47]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- /* release the lock, making sure not to overwrite
- anyone else's lock */
- set (rptrAddrSearchLock = lock_value+1,
- rptrAddrSearchStatus = notInUse,
- rptrAddrSearchOwner = '')
-
- A management station first retrieves the values of
- the appropriate instances of the rptrAddrSearchLock
- and rptrAddrSearchStatus objects, periodically
- repeating the retrieval if necessary, until the value
- of rptrAddrSearchStatus is 'notInUse'. The
- management station then tries to set the same
- instance of the rptrAddrSearchLock object to the
- value it just retrieved, the same instance of the
- rptrAddrSearchStatus object to 'inUse', and the
- corresponding instance of rptrAddrSearchOwner to a
- value indicating itself. If the set operation
- succeeds, then the management station has obtained
- ownership of the rptrAddrSearchEntry, and the value
- of rptrAddrSearchLock is incremented by the agent (as
- per the semantics of TestAndIncr). Failure of the
- set operation indicates that some other manager has
- obtained ownership of the rptrAddrSearchEntry.
-
- Once ownership is obtained, the management station
- can proceed with the search operation. Note that the
- agent will reset rptrAddrSearchStatus to 'notInUse'
- if it has been in the 'inUse' state for an abnormally
- long period of time, to prevent a misbehaving manager
- from permanently locking the entry. It is suggested
- that this timeout period be between one and five
- minutes.
-
- When the management station has completed its search
- operation, it should free the entry by setting
- the instance of the rptrAddrSearchLock object to the
- previous value + 1, the instance of the
- rptrAddrSearchStatus to 'notInUse', and the instance
- of rptrAddrSearchOwner to a zero length string. This
- is done to prevent overwriting another station's
- lock."
- ::= { rptrAddrTrackRptrInfo 1 }
-
- rptrAddrSearchEntry OBJECT-TYPE
- SYNTAX RptrAddrSearchEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
-
-
-
- de Graaf, et. al. Standards Track [Page 48]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- "An entry containing objects for invoking an address
- search on a repeater."
- INDEX { rptrInfoId }
- ::= { rptrAddrSearchTable 1 }
-
- RptrAddrSearchEntry ::=
- SEQUENCE {
- rptrAddrSearchLock TestAndIncr,
- rptrAddrSearchStatus INTEGER,
- rptrAddrSearchAddress MacAddress,
- rptrAddrSearchState INTEGER,
- rptrAddrSearchGroup Integer32,
- rptrAddrSearchPort Integer32,
- rptrAddrSearchOwner OwnerString
- }
-
-
- rptrAddrSearchLock OBJECT-TYPE
- SYNTAX TestAndIncr
- MAX-ACCESS read-write
- STATUS current
- DESCRIPTION
- "This object is used by a management station as an
- advisory lock for this rptrAddrSearchEntry."
- ::= { rptrAddrSearchEntry 1 }
-
- rptrAddrSearchStatus OBJECT-TYPE
- SYNTAX INTEGER {
- notInUse(1),
- inUse(2)
- }
- MAX-ACCESS read-write
- STATUS current
- DESCRIPTION
- "This object is used to indicate that some management
- station is currently using this rptrAddrSearchEntry.
- Cooperating managers should set this object to
- 'notInUse' when they are finished using this entry.
- The agent will automatically set the value of this
- object to 'notInUse' if it has been set to 'inUse'
- for an unusually long period of time."
- ::= { rptrAddrSearchEntry 2 }
-
- rptrAddrSearchAddress OBJECT-TYPE
- SYNTAX MacAddress
- MAX-ACCESS read-write
- STATUS current
- DESCRIPTION
-
-
-
- de Graaf, et. al. Standards Track [Page 49]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- "This object is used to search for a specified MAC
- address. When this object is set, an address search
- begins. This automatically sets the corresponding
- instance of the rptrAddrSearchState object to 'none'
- and the corresponding instances of the
- rptrAddrSearchGroup and rptrAddrSearchPort objects to
- 0.
-
- When a valid frame is received by this repeater with
- a source MAC address which matches the current value
- of rptrAddrSearchAddress, the agent will update the
- corresponding instances of rptrAddrSearchState,
- rptrAddrSearchGroup and rptrAddrSearchPort to reflect
- the current status of the search, and the group and
- port on which the frame was seen."
- ::= { rptrAddrSearchEntry 3 }
-
- rptrAddrSearchState OBJECT-TYPE
- SYNTAX INTEGER {
- none(1),
- single(2),
- multiple(3)
- }
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The current state of the MAC address search on this
- repeater. This object is initialized to 'none' when
- the corresponding instance of rptrAddrSearchAddress
- is set. If the agent detects the address on exactly
- one port, it will set this object to 'single', and
- set the corresponding instances of
- rptrAddrSearchGroup and rptrAddrSearchPort to reflect
- the group and port on which the address was heard.
- If the agent detects the address on more than one
- port, it will set this object to 'multiple'."
- ::= { rptrAddrSearchEntry 4 }
-
- rptrAddrSearchGroup OBJECT-TYPE
- SYNTAX Integer32 (0..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The group from which an error-free frame whose
- source address is equal to the corresponding instance
- of rptrAddrSearchAddress has been received. The
- value of this object is undefined when the
- corresponding instance of rptrAddrSearchState is
-
-
-
- de Graaf, et. al. Standards Track [Page 50]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- equal to 'none' or 'multiple'."
- ::= { rptrAddrSearchEntry 5 }
-
- rptrAddrSearchPort OBJECT-TYPE
- SYNTAX Integer32 (0..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The port rom which an error-free frame whose
- source address is equal to the corresponding instance
- of rptrAddrSearchAddress has been received. The
- value of this object is undefined when the
- corresponding instance of rptrAddrSearchState is
- equal to 'none' or 'multiple'."
- ::= { rptrAddrSearchEntry 6 }
-
- rptrAddrSearchOwner OBJECT-TYPE
- SYNTAX OwnerString
- MAX-ACCESS read-write
- STATUS current
- DESCRIPTION
- "The entity which currently has 'ownership' of this
- rptrAddrSearchEntry."
- ::= { rptrAddrSearchEntry 7 }
-
-
- --
- -- The Port Address Tracking Table
- --
- -- This table provides a way for a network management
- -- application to passively gather information (using
- -- read-only privileges) about which network addresses
- -- are connected to which ports of a repeater.
- --
-
- rptrAddrTrackTable OBJECT-TYPE
- SYNTAX SEQUENCE OF RptrAddrTrackEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "Table of address mapping information about the
- ports."
- ::= { rptrAddrTrackPortInfo 1 }
-
- rptrAddrTrackEntry OBJECT-TYPE
- SYNTAX RptrAddrTrackEntry
- MAX-ACCESS not-accessible
- STATUS current
-
-
-
- de Graaf, et. al. Standards Track [Page 51]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- DESCRIPTION
- "An entry in the table, containing address mapping
- information about a single port."
- INDEX { rptrAddrTrackGroupIndex, rptrAddrTrackPortIndex }
- ::= { rptrAddrTrackTable 1 }
-
- RptrAddrTrackEntry ::=
- SEQUENCE {
- rptrAddrTrackGroupIndex
- INTEGER,
- rptrAddrTrackPortIndex
- INTEGER,
- rptrAddrTrackLastSourceAddress -- DEPRECATED OBJECT
- MacAddress,
- rptrAddrTrackSourceAddrChanges
- Counter32,
- rptrAddrTrackNewLastSrcAddress
- OptMacAddr,
- rptrAddrTrackCapacity
- Integer32
- }
-
- rptrAddrTrackGroupIndex OBJECT-TYPE
- SYNTAX INTEGER (1..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This object identifies the group containing the
- port for which this entry contains information."
- ::= { rptrAddrTrackEntry 1 }
-
- rptrAddrTrackPortIndex OBJECT-TYPE
- SYNTAX INTEGER (1..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This object identifies the port within the group
- for which this entry contains information."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.1, aPortID."
- ::= { rptrAddrTrackEntry 2 }
-
- rptrAddrTrackLastSourceAddress OBJECT-TYPE
- SYNTAX MacAddress
- MAX-ACCESS read-only
- STATUS deprecated
- DESCRIPTION
- "********* THIS OBJECT IS DEPRECATED **********
-
-
-
- de Graaf, et. al. Standards Track [Page 52]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- This object is the SourceAddress of the last
- readable frame (i.e., counted by
- rptrMonitorPortReadableFrames) received by this
- port.
-
- This object has been deprecated because its value
- is undefined when no frames have been observed on
- this port. The replacement object is
- rptrAddrTrackNewLastSrcAddress."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.18, aLastSourceAddress."
- ::= { rptrAddrTrackEntry 3 }
-
- rptrAddrTrackSourceAddrChanges OBJECT-TYPE
- SYNTAX Counter32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This counter is incremented by one for each time
- that the rptrAddrTrackLastSourceAddress attribute
- for this port has changed.
-
- This may indicate whether a link is connected to a
- single DTE or another multi-user segment.
-
- A discontinuity may occur in the value when the
- value of object rptrMonitorPortLastChange changes.
-
- The approximate minimum time for rollover of this
- counter is 81 hours in a 10Mb/s repeater."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.19, aSourceAddressChanges."
- ::= { rptrAddrTrackEntry 4 }
-
- rptrAddrTrackNewLastSrcAddress OBJECT-TYPE
- SYNTAX OptMacAddr
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This object is the SourceAddress of the last
- readable frame (i.e., counted by
- rptrMonitorPortReadableFrames) received by this
- port. If no frames have been received by this
- port since the agent began monitoring the port
- activity, the agent shall return a string of
- length zero."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.18, aLastSourceAddress."
-
-
-
- de Graaf, et. al. Standards Track [Page 53]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- ::= { rptrAddrTrackEntry 5 }
-
- rptrAddrTrackCapacity OBJECT-TYPE
- SYNTAX Integer32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The maximum number of addresses that can be
- detected on this port. This value indicates
- to the maximum number of entries in the
- rptrExtAddrTrackTable relative to this port.
-
- If this object has the value of 1, the agent
- implements only the LastSourceAddress mechanism
- described by RFC 1368 or RFC 1516."
- ::= { rptrAddrTrackEntry 6 }
-
-
- -- Table for multiple addresses per port
-
- rptrExtAddrTrackTable OBJECT-TYPE
- SYNTAX SEQUENCE OF RptrExtAddrTrackEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "A table to extend the address tracking table (i.e.,
- rptrAddrTrackTable) with a list of source MAC
- addresses that were recently received on each port.
- The number of ports is the same as the number
- of entries in table rptrPortTable. The number of
- entries in this table depends on the agent/repeater
- implementation and the number of different
- addresses received on each port.
-
- The first entry for each port contains
- the same MAC address that is given by the
- rptrAddrTrackNewLastSrcAddress for that port.
-
- Entries in this table for a particular port are
- retained when that port is switched from one
- repeater to another.
-
- The ordering of MAC addresses listed for a
- particular port is implementation dependent."
- ::= { rptrAddrTrackPortInfo 2 }
-
- rptrExtAddrTrackEntry OBJECT-TYPE
- SYNTAX RptrExtAddrTrackEntry
-
-
-
- de Graaf, et. al. Standards Track [Page 54]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "A row in the table of extended address tracking
- information for ports. Entries can not be directly
- created or deleted via SNMP operations."
- INDEX { rptrAddrTrackGroupIndex,
- rptrAddrTrackPortIndex,
- rptrExtAddrTrackMacIndex }
- ::= { rptrExtAddrTrackTable 1 }
-
- RptrExtAddrTrackEntry ::= SEQUENCE {
- rptrExtAddrTrackMacIndex Integer32,
- rptrExtAddrTrackSourceAddress MacAddress
- }
-
- rptrExtAddrTrackMacIndex OBJECT-TYPE
- SYNTAX Integer32 (1..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The index of a source MAC address seen on
- the port.
-
- The ordering of MAC addresses listed for a
- particular port is implementation dependent.
-
- There is no implied relationship between a
- particular index and a particular MAC
- address. The index for a particular MAC
- address may change without notice."
- ::= { rptrExtAddrTrackEntry 1 }
-
- rptrExtAddrTrackSourceAddress OBJECT-TYPE
- SYNTAX MacAddress
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The source MAC address from a readable frame
- (i.e., counted by rptrMonitorPortReadableFrames)
- recently received by the port."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.3.1.18, aLastSourceAddress."
- ::= { rptrExtAddrTrackEntry 2 }
-
-
- -- The Repeater Top "N" Port Group
-
-
-
-
- de Graaf, et. al. Standards Track [Page 55]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- -- The Repeater Top N Port group is used to prepare reports that
- -- describe a list of ports ordered by one of the statistics in the
- -- Repeater Monitor Port Table. The statistic chosen by the
- -- management station is sampled over a management
- -- station-specified time interval, making the report rate based.
- -- The management station also specifies the number of ports that
- -- are reported.
- --
- -- The rptrTopNPortControlTable is used to initiate the generation
- -- of a report. The management station may select the parameters
- -- of such a report, such as which repeater, which statistic, how
- -- many ports, and the start & stop times of the sampling. When
- -- the report is prepared, entries are created in the
- -- rptrTopNPortTable associated with the relevent
- -- rptrTopNControlEntry. These entries are static for
- -- each report after it has been prepared.
-
- -- Note that counter discontinuities may appear in some
- -- implementations if ports' assignment to repeaters changes
- -- during the collection of data for a Top "N" report.
- -- A management application could read the corresponding
- -- rptrMonitorPortLastChange timestamp in order to check
- -- whether a discontinuity occurred.
-
-
- rptrTopNPortControlTable OBJECT-TYPE
- SYNTAX SEQUENCE OF RptrTopNPortControlEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "A table of control records for reports on the top `N'
- ports for the rate of a selected counter. The number
- of entries depends on the configuration of the agent.
- The maximum number of entries is implementation
- dependent."
- ::= { rptrTopNPortInfo 1 }
-
- rptrTopNPortControlEntry OBJECT-TYPE
- SYNTAX RptrTopNPortControlEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "A set of parameters that control the creation of a
- report of the top N ports according to several metrics."
- INDEX { rptrTopNPortControlIndex }
- ::= { rptrTopNPortControlTable 1 }
-
- RptrTopNPortControlEntry ::= SEQUENCE {
-
-
-
- de Graaf, et. al. Standards Track [Page 56]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- rptrTopNPortControlIndex
- Integer32,
- rptrTopNPortRepeaterId
- Integer32,
- rptrTopNPortRateBase
- INTEGER,
- rptrTopNPortTimeRemaining
- Integer32,
- rptrTopNPortDuration
- Integer32,
- rptrTopNPortRequestedSize
- Integer32,
- rptrTopNPortGrantedSize
- Integer32,
- rptrTopNPortStartTime
- TimeStamp,
- rptrTopNPortOwner
- OwnerString,
- rptrTopNPortRowStatus
- RowStatus
- }
-
- rptrTopNPortControlIndex OBJECT-TYPE
- SYNTAX Integer32 (1 .. 65535)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "An index that uniquely identifies an entry in the
- rptrTopNPortControl table. Each such entry defines
- one top N report prepared for a repeater or system."
- ::= { rptrTopNPortControlEntry 1 }
-
- rptrTopNPortRepeaterId OBJECT-TYPE
- SYNTAX Integer32 (0..2147483647)
- MAX-ACCESS read-create
- STATUS current
- DESCRIPTION
- "Identifies the repeater for which a top N report will
- be prepared (see rptrInfoId). If the value of this
- object is positive, only ports assigned to this repeater
- will be used to form the list in which to order the
- Top N table. If this value is zero, all ports will be
- eligible for inclusion on the list.
-
- The value of this object may not be modified if the
- associated rptrTopNPortRowStatus object is equal to
- active(1).
-
-
-
-
- de Graaf, et. al. Standards Track [Page 57]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- If, for a particular row in this table, the repeater
- specified by the value of this object goes away (is
- removed from the rptrInfoTable) while the associated
- rptrTopNPortRowStatus object is equal to active(1),
- the row in this table is preserved by the agent but
- the value of rptrTopNPortRowStatus is changed to
- notInService(2), and the agent may time out the row
- if appropriate. If the specified repeater comes
- back (reappears in the rptrInfoTable) before the row
- has been timed out, the management station must set
- the value of the rptrTopNPortRowStatus object back
- to active(1) if desired (the agent doesn't do this
- automatically)."
- ::= { rptrTopNPortControlEntry 2 }
-
- rptrTopNPortRateBase OBJECT-TYPE
- SYNTAX INTEGER {
- readableFrames(1),
- readableOctets(2),
- fcsErrors(3),
- alignmentErrors(4),
- frameTooLongs(5),
- shortEvents(6),
- runts(7),
- collisions(8),
- lateEvents(9),
- veryLongEvents(10),
- dataRateMismatches(11),
- autoPartitions(12),
- totalErrors(13),
- isolates(14),
- symbolErrors(15)
- }
- MAX-ACCESS read-create
- STATUS current
- DESCRIPTION
- "The monitored variable, which the rptrTopNPortRate
- variable is based upon.
-
- The value of this object may not be modified if
- the associated rptrTopNPortRowStatus object has
- a value of active(1)."
- ::= { rptrTopNPortControlEntry 3 }
-
- rptrTopNPortTimeRemaining OBJECT-TYPE
- SYNTAX Integer32 (0..2147483647)
- MAX-ACCESS read-create
- STATUS current
-
-
-
- de Graaf, et. al. Standards Track [Page 58]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- DESCRIPTION
- "The number of seconds left in the report
- currently being collected. When this object
- is modified by the management station, a new
- collection is started, possibly aborting a
- currently running report. The new value is
- used as the requested duration of this report,
- which is loaded into the associated
- rptrTopNPortDuration object.
-
- When this object is set to a non-zero value,
- any associated rptrTopNPortEntries shall be
- made inaccessible by the agent. While the value
- of this object is non-zero, it decrements by one
- per second until it reaches zero. During this
- time, all associated rptrTopNPortEntries shall
- remain inaccessible. At the time that this object
- decrements to zero, the report is made accessible
- in the rptrTopNPortTable. Thus, the rptrTopNPort
- table needs to be created only at the end of the
- collection interval.
-
- If the value of this object is set to zero
- while the associated report is running, the
- running report is aborted and no associated
- rptrTopNPortEntries are created."
- DEFVAL { 0 }
- ::= { rptrTopNPortControlEntry 4 }
-
- rptrTopNPortDuration OBJECT-TYPE
- SYNTAX Integer32 (0..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The number of seconds that this report has
- collected during the last sampling interval,
- or if this report is currently being collected,
- the number of seconds that this report is being
- collected during this sampling interval.
-
- When the associated rptrTopNPortTimeRemaining
- object is set, this object shall be set by the
- agent to the same value and shall not be modified
- until the next time the rptrTopNPortTimeRemaining
- is set.
-
- This value shall be zero if no reports have been
- requested for this rptrTopNPortControlEntry."
-
-
-
- de Graaf, et. al. Standards Track [Page 59]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- ::= { rptrTopNPortControlEntry 5 }
-
- rptrTopNPortRequestedSize OBJECT-TYPE
- SYNTAX Integer32
- MAX-ACCESS read-create
- STATUS current
- DESCRIPTION
- "The maximum number of repeater ports requested
- for the Top N Table.
-
- When this object is created or modified, the
- agent should set rptrTopNPortGrantedSize as close
- to this object as is possible for the particular
- implementation and available resources."
- DEFVAL { 10 }
- ::= { rptrTopNPortControlEntry 6 }
-
- rptrTopNPortGrantedSize OBJECT-TYPE
- SYNTAX Integer32 (0..65535)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The maximum number of repeater ports in the
- top N table.
-
- When the associated rptrTopNPortRequestedSize object is
- created or modified, the agent should set this object as
- closely to the requested value as is possible for the
- particular implementation and available resources. The
- agent must not lower this value except as a result of a
- set to the associated rptrTopNPortRequestedSize object."
- ::= { rptrTopNPortControlEntry 7 }
-
- rptrTopNPortStartTime OBJECT-TYPE
- SYNTAX TimeStamp
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The value of sysUpTime when this top N report was
- last started. In other words, this is the time that
- the associated rptrTopNPortTimeRemaining object was
- modified to start the requested report.
-
- If the report has not yet been started, the value
- of this object is zero."
- ::= { rptrTopNPortControlEntry 8 }
-
- rptrTopNPortOwner OBJECT-TYPE
-
-
-
- de Graaf, et. al. Standards Track [Page 60]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- SYNTAX OwnerString
- MAX-ACCESS read-create
- STATUS current
- DESCRIPTION
- "The entity that configured this entry and is
- using the resources assigned to it."
- ::= { rptrTopNPortControlEntry 9 }
-
- rptrTopNPortRowStatus OBJECT-TYPE
- SYNTAX RowStatus
- MAX-ACCESS read-create
- STATUS current
- DESCRIPTION
- "The status of this row.
-
- If the value of this object is not equal to
- active(1), all associated entries in the
- rptrTopNPortTable shall be deleted by the
- agent."
- ::= { rptrTopNPortControlEntry 10 }
-
-
- -- Top "N" reports
-
- rptrTopNPortTable OBJECT-TYPE
- SYNTAX SEQUENCE OF RptrTopNPortEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
- "A table of reports for the top `N' ports based on
- setting of associated control table entries. The
- maximum number of entries depends on the number
- of entries in table rptrTopNPortControlTable and
- the value of object rptrTopNPortGrantedSize for
- each entry.
-
- For each entry in the rptrTopNPortControlTable,
- repeater ports with the highest value of
- rptrTopNPortRate shall be placed in this table
- in decreasing order of that rate until there is
- no more room or until there are no more ports."
- ::= { rptrTopNPortInfo 2 }
-
- rptrTopNPortEntry OBJECT-TYPE
- SYNTAX RptrTopNPortEntry
- MAX-ACCESS not-accessible
- STATUS current
- DESCRIPTION
-
-
-
- de Graaf, et. al. Standards Track [Page 61]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- "A set of statistics for a repeater port that is
- part of a top N report."
- INDEX { rptrTopNPortControlIndex,
- rptrTopNPortIndex }
- ::= { rptrTopNPortTable 1 }
-
- RptrTopNPortEntry ::= SEQUENCE {
- rptrTopNPortIndex
- Integer32,
- rptrTopNPortGroupIndex
- Integer32,
- rptrTopNPortPortIndex
- Integer32,
- rptrTopNPortRate
- Gauge32
- }
-
- rptrTopNPortIndex OBJECT-TYPE
- SYNTAX Integer32 (1..65535)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "An index that uniquely identifies an entry in
- the rptrTopNPort table among those in the same
- report. This index is between 1 and N, where N
- is the number of entries in this report. Increasing
- values of rptrTopNPortIndex shall be assigned to
- entries with decreasing values of rptrTopNPortRate
- until index N is assigned to the entry with the
- lowest value of rptrTopNPortRate or there are no
- more rptrTopNPortEntries.
-
- No ports are included in a report where their
- value of rptrTopNPortRate would be zero."
- ::= { rptrTopNPortEntry 1 }
-
- rptrTopNPortGroupIndex OBJECT-TYPE
- SYNTAX Integer32 (1..2147483647)
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "This object identifes the group containing
- the port for this entry. (See also object
- type rptrGroupIndex.)"
- ::= { rptrTopNPortEntry 2 }
-
- rptrTopNPortPortIndex OBJECT-TYPE
- SYNTAX Integer32 (1..2147483647)
-
-
-
- de Graaf, et. al. Standards Track [Page 62]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The index of the repeater port.
- (See object type rptrPortIndex.)"
- ::= { rptrTopNPortEntry 3 }
-
- rptrTopNPortRate OBJECT-TYPE
- SYNTAX Gauge32
- MAX-ACCESS read-only
- STATUS current
- DESCRIPTION
- "The amount of change in the selected variable
- during this sampling interval for the identified
- port. The selected variable is that port's
- instance of the object selected by
- rptrTopNPortRateBase."
- ::= { rptrTopNPortEntry 4 }
-
-
-
- -- Notifications for use by Repeaters
-
- rptrHealth NOTIFICATION-TYPE
- OBJECTS { rptrOperStatus }
- STATUS deprecated
- DESCRIPTION
- "********* THIS OBJECT IS DEPRECATED **********
-
- In a system containing a single managed repeater,
- the rptrHealth notification conveys information
- related to the operational status of the repeater.
- It is sent either when the value of
- rptrOperStatus changes, or upon completion of a
- non-disruptive test.
-
- The rptrHealth notification must contain the
- rptrOperStatus object. The agent may optionally
- include the rptrHealthText object in the varBind
- list. See the rptrOperStatus and rptrHealthText
- objects for descriptions of the information that
- is sent.
-
- The agent must throttle the generation of
- consecutive rptrHealth traps so that there is at
- least a five-second gap between traps of this
- type. When traps are throttled, they are dropped,
- not queued for sending at a future time. (Note
-
-
-
- de Graaf, et. al. Standards Track [Page 63]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- that 'generating' a trap means sending to all
- configured recipients.)"
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.1.3.1, nRepeaterHealth
- notification."
- ::= { snmpDot3RptrMgt 0 1 }
-
- rptrGroupChange NOTIFICATION-TYPE
- OBJECTS { rptrGroupIndex }
- STATUS deprecated
- DESCRIPTION
- "********* THIS OBJECT IS DEPRECATED **********
-
- In a system containing a single managed repeater,
- this notification is sent when a change occurs in the
- group structure of the repeater. This occurs only
- when a group is logically or physically removed
- from or added to a repeater. The varBind list
- contains the identifier of the group that was
- removed or added.
-
- The agent must throttle the generation of
- consecutive rptrGroupChange traps for the same
- group so that there is at least a five-second gap
- between traps of this type. When traps are
- throttled, they are dropped, not queued for
- sending at a future time. (Note that 'generating'
- a trap means sending to all configured
- recipients.)"
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.1.3.3, nGroupMapChange
- notification."
- ::= { snmpDot3RptrMgt 0 2 }
-
- rptrResetEvent NOTIFICATION-TYPE
- OBJECTS { rptrOperStatus }
- STATUS deprecated
- DESCRIPTION
- "********* THIS OBJECT IS DEPRECATED **********
-
- In a system containing a single managed repeater-unit,
- the rptrResetEvent notification conveys information
- related to the operational status of the repeater.
- This trap is sent on completion of a repeater
- reset action. A repeater reset action is defined
- as an a transition to the START state of Fig 9-2
- in section 9 [IEEE 802.3 Std], when triggered by a
- management command (e.g., an SNMP Set on the
-
-
-
- de Graaf, et. al. Standards Track [Page 64]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- rptrReset object).
-
- The agent must throttle the generation of
- consecutive rptrResetEvent traps so that there is
- at least a five-second gap between traps of this
- type. When traps are throttled, they are dropped,
- not queued for sending at a future time. (Note
- that 'generating' a trap means sending to all
- configured recipients.)
-
- The rptrResetEvent trap is not sent when the agent
- restarts and sends an SNMP coldStart or warmStart
- trap. However, it is recommended that a repeater
- agent send the rptrOperStatus object as an
- optional object with its coldStart and warmStart
- trap PDUs.
-
- The rptrOperStatus object must be included in the
- varbind list sent with this trap. The agent may
- optionally include the rptrHealthText object as
- well."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.1.3.2, nRepeaterReset
- notification."
- ::= { snmpDot3RptrMgt 0 3 }
-
-
- -- Notifications for repeaters in a multiple-repeater implementation.
- -- An implementation may send either the single-repeater OR
- -- multiple-repeater version of these notifications (1 or 4; 2 or 5)
- -- but not both.
-
- rptrInfoHealth NOTIFICATION-TYPE
- OBJECTS { rptrInfoOperStatus }
- STATUS current
- DESCRIPTION
- "In a system containing multiple managed repeaters,
- the rptrInfoHealth notification conveys information
- related to the operational status of a repeater.
- It is sent either when the value of rptrInfoOperStatus
- changes, or upon completion of a non-disruptive test.
-
- The agent must throttle the generation of
- consecutive rptrInfoHealth notifications for
- the same repeater so that there is at least
- a five-second gap between notifications of this type.
- When notifications are throttled, they are dropped,
- not queued for sending at a future time. (Note
-
-
-
- de Graaf, et. al. Standards Track [Page 65]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- that 'generating' a notification means sending
- to all configured recipients.)"
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.1.3.1, nRepeaterHealth
- notification."
- ::= { snmpDot3RptrMgt 0 4 }
-
- rptrInfoResetEvent NOTIFICATION-TYPE
- OBJECTS { rptrInfoOperStatus }
- STATUS current
- DESCRIPTION
- "In a system containing multiple managed
- repeaters, the rptrInfoResetEvent notification
- conveys information related to the operational
- status of a repeater. This notification is sent
- on completion of a repeater reset action. A
- repeater reset action is defined as a transition
- to the START state of Fig 9-2 in section 9 of
- [IEEE 802.3 Std], when triggered by a management
- command (e.g., an SNMP Set on the rptrInfoReset
- object).
-
- The agent must throttle the generation of
- consecutive rptrInfoResetEvent notifications for
- a single repeater so that there is at least
- a five-second gap between notifications of
- this type. When notifications are throttled,
- they are dropped, not queued for sending at
- a future time. (Note that 'generating' a
- notification means sending to all configured
- recipients.)
-
- The rptrInfoResetEvent is not sent when the
- agent restarts and sends an SNMP coldStart or
- warmStart trap. However, it is recommended that
- a repeater agent send the rptrInfoOperStatus
- object as an optional object with its coldStart
- and warmStart trap PDUs."
- REFERENCE
- "[IEEE 802.3 Mgt], 30.4.1.3.2, nRepeaterReset
- notification."
- ::= { snmpDot3RptrMgt 0 5 }
-
-
- -- Conformance information
-
- snmpRptrModConf
- OBJECT IDENTIFIER ::= { snmpRptrMod 1 }
-
-
-
- de Graaf, et. al. Standards Track [Page 66]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- snmpRptrModCompls
- OBJECT IDENTIFIER ::= { snmpRptrModConf 1 }
- snmpRptrModObjGrps
- OBJECT IDENTIFIER ::= { snmpRptrModConf 2 }
- snmpRptrModNotGrps
- OBJECT IDENTIFIER ::= { snmpRptrModConf 3 }
-
-
- -- Object groups
-
- snmpRptrGrpBasic1516 OBJECT-GROUP
- OBJECTS { rptrGroupCapacity,
- rptrOperStatus,
- rptrHealthText,
- rptrReset,
- rptrNonDisruptTest,
- rptrTotalPartitionedPorts,
-
- rptrGroupIndex,
- rptrGroupDescr,
- rptrGroupObjectID,
- rptrGroupOperStatus,
- rptrGroupLastOperStatusChange,
- rptrGroupPortCapacity,
-
- rptrPortGroupIndex,
- rptrPortIndex,
- rptrPortAdminStatus,
- rptrPortAutoPartitionState,
- rptrPortOperStatus }
- STATUS deprecated
- DESCRIPTION
- "********* THIS GROUP IS DEPRECATED **********
-
- Basic group from RFCs 1368 and 1516.
-
- NOTE: this object group is DEPRECATED and replaced
- with snmpRptrGrpBasic."
- ::= { snmpRptrModObjGrps 1 }
-
- snmpRptrGrpMonitor1516 OBJECT-GROUP
- OBJECTS { rptrMonitorTransmitCollisions,
-
- rptrMonitorGroupIndex,
- rptrMonitorGroupTotalFrames,
- rptrMonitorGroupTotalOctets,
- rptrMonitorGroupTotalErrors,
-
-
-
-
- de Graaf, et. al. Standards Track [Page 67]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- rptrMonitorPortGroupIndex,
- rptrMonitorPortIndex,
- rptrMonitorPortReadableFrames,
- rptrMonitorPortReadableOctets,
- rptrMonitorPortFCSErrors,
- rptrMonitorPortAlignmentErrors,
- rptrMonitorPortFrameTooLongs,
- rptrMonitorPortShortEvents,
- rptrMonitorPortRunts,
- rptrMonitorPortCollisions,
- rptrMonitorPortLateEvents,
- rptrMonitorPortVeryLongEvents,
- rptrMonitorPortDataRateMismatches,
- rptrMonitorPortAutoPartitions,
- rptrMonitorPortTotalErrors }
- STATUS deprecated
- DESCRIPTION
- "********* THIS GROUP IS DEPRECATED **********
-
- Monitor group from RFCs 1368 and 1516.
-
- NOTE: this object group is DEPRECATED and replaced
- with snmpRptrGrpMonitor."
- ::= { snmpRptrModObjGrps 2 }
-
- snmpRptrGrpAddrTrack1368 OBJECT-GROUP
- OBJECTS { rptrAddrTrackGroupIndex,
- rptrAddrTrackPortIndex,
- rptrAddrTrackLastSourceAddress,
- rptrAddrTrackSourceAddrChanges }
- STATUS obsolete
- DESCRIPTION
- "Address tracking group from RFC 1368.
-
- NOTE: this object group is OBSOLETE and replaced
- with snmpRptrGrpAddrTrack1516."
- ::= { snmpRptrModObjGrps 3 }
-
- snmpRptrGrpAddrTrack1516 OBJECT-GROUP
- OBJECTS { rptrAddrTrackGroupIndex,
- rptrAddrTrackPortIndex,
- rptrAddrTrackLastSourceAddress,
- rptrAddrTrackSourceAddrChanges,
- rptrAddrTrackNewLastSrcAddress }
- STATUS deprecated
- DESCRIPTION
- "********* THIS GROUP IS DEPRECATED **********
-
-
-
-
- de Graaf, et. al. Standards Track [Page 68]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- Address tracking group from RFC 1516.
-
- NOTE: this object group is DEPRECATED and
- replaced with snmpRptrGrpAddrTrack."
- ::= { snmpRptrModObjGrps 4 }
-
- snmpRptrGrpBasic OBJECT-GROUP
- OBJECTS { rptrGroupIndex,
- rptrGroupObjectID,
- rptrGroupOperStatus,
- rptrGroupPortCapacity,
-
- rptrPortGroupIndex,
- rptrPortIndex,
- rptrPortAdminStatus,
- rptrPortAutoPartitionState,
- rptrPortOperStatus,
- rptrPortRptrId,
-
- rptrInfoId,
- rptrInfoRptrType,
- rptrInfoOperStatus,
- rptrInfoReset,
- rptrInfoPartitionedPorts,
- rptrInfoLastChange }
- STATUS current
- DESCRIPTION
- "Basic group for a system with one or more
- repeater-units in multi-segment (post-RFC 1516)
- version of the MIB module."
- ::= { snmpRptrModObjGrps 5 }
-
- snmpRptrGrpMonitor OBJECT-GROUP
- OBJECTS { rptrMonitorPortGroupIndex,
- rptrMonitorPortIndex,
- rptrMonitorPortReadableFrames,
- rptrMonitorPortReadableOctets,
- rptrMonitorPortFCSErrors,
- rptrMonitorPortAlignmentErrors,
- rptrMonitorPortFrameTooLongs,
- rptrMonitorPortShortEvents,
- rptrMonitorPortRunts,
- rptrMonitorPortCollisions,
- rptrMonitorPortLateEvents,
- rptrMonitorPortVeryLongEvents,
- rptrMonitorPortDataRateMismatches,
- rptrMonitorPortAutoPartitions,
- rptrMonitorPortTotalErrors,
-
-
-
- de Graaf, et. al. Standards Track [Page 69]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- rptrMonitorPortLastChange,
-
- rptrMonTxCollisions,
- rptrMonTotalFrames,
- rptrMonTotalErrors,
- rptrMonTotalOctets }
- STATUS current
- DESCRIPTION
- "Monitor group for a system with one or more
- repeater-units in multi-segment (post-RFC 1516)
- version of the MIB module."
- ::= { snmpRptrModObjGrps 6 }
-
- snmpRptrGrpMonitor100 OBJECT-GROUP
- OBJECTS { rptrMonitorPortIsolates,
- rptrMonitorPortSymbolErrors,
- rptrMonitorPortUpper32Octets,
-
- rptrMonUpper32TotalOctets }
- STATUS current
- DESCRIPTION
- "Monitor group for 100Mb/s ports and repeaters
- in a system with one or more repeater-units in
- multi-segment (post-RFC 1516) version of the MIB
- module. Systems which support Counter64 should
- also implement snmpRptrGrpMonitor100w64."
- ::= { snmpRptrModObjGrps 7 }
-
- snmpRptrGrpMonitor100w64 OBJECT-GROUP
- OBJECTS { rptrMonitorPortHCReadableOctets,
- rptrMonHCTotalOctets }
- STATUS current
- DESCRIPTION
- "Monitor group for 100Mb/s ports and repeaters in a
- system with one or more repeater-units and support
- for Counter64."
- ::= { snmpRptrModObjGrps 8 }
-
- snmpRptrGrpAddrTrack OBJECT-GROUP
- OBJECTS { rptrAddrTrackGroupIndex,
- rptrAddrTrackPortIndex,
- rptrAddrTrackSourceAddrChanges,
- rptrAddrTrackNewLastSrcAddress,
- rptrAddrTrackCapacity }
- STATUS current
- DESCRIPTION
- "Passive address tracking group for post-RFC 1516
- version of the MIB module."
-
-
-
- de Graaf, et. al. Standards Track [Page 70]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- ::= { snmpRptrModObjGrps 9 }
-
- snmpRptrGrpExtAddrTrack OBJECT-GROUP
- OBJECTS { rptrExtAddrTrackMacIndex,
- rptrExtAddrTrackSourceAddress }
- STATUS current
- DESCRIPTION
- "Extended passive address tracking group for
- a system with one or more repeater-units in
- post-RFC 1516 version of the MIB module."
- ::= { snmpRptrModObjGrps 10 }
-
- snmpRptrGrpRptrAddrSearch OBJECT-GROUP
- OBJECTS { rptrAddrSearchLock,
- rptrAddrSearchStatus,
- rptrAddrSearchAddress,
- rptrAddrSearchState,
- rptrAddrSearchGroup,
- rptrAddrSearchPort,
- rptrAddrSearchOwner }
- STATUS current
- DESCRIPTION
- "Active MAC address search group and topology
- mapping support for repeaters."
- ::= { snmpRptrModObjGrps 11 }
-
- snmpRptrGrpTopNPort OBJECT-GROUP
- OBJECTS { rptrTopNPortControlIndex,
- rptrTopNPortRepeaterId,
- rptrTopNPortRateBase,
- rptrTopNPortTimeRemaining,
- rptrTopNPortDuration,
- rptrTopNPortRequestedSize,
- rptrTopNPortGrantedSize,
- rptrTopNPortStartTime,
- rptrTopNPortOwner,
- rptrTopNPortRowStatus,
- rptrTopNPortIndex,
- rptrTopNPortGroupIndex,
- rptrTopNPortPortIndex,
- rptrTopNPortRate }
- STATUS current
- DESCRIPTION
- "Top `N' group for repeater ports."
- ::= { snmpRptrModObjGrps 12 }
-
-
- -- Compliances
-
-
-
- de Graaf, et. al. Standards Track [Page 71]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- snmpRptrModComplRFC1368 MODULE-COMPLIANCE
- STATUS obsolete
- DESCRIPTION
- "Compliance for RFC 1368.
-
- NOTE: this module compliance is OBSOLETE and
- replaced by snmpRptrModComplRFC1516."
-
- MODULE -- this module
- MANDATORY-GROUPS { snmpRptrGrpBasic1516 }
-
- GROUP snmpRptrGrpMonitor1516
- DESCRIPTION
- "Implementation of this optional group is
- recommended for systems which have the
- instrumentation to do performance monitoring."
-
- GROUP snmpRptrGrpAddrTrack1368
- DESCRIPTION
- "Implementation of this group is
- recommended for systems which have
- the necessary instrumentation."
-
- ::= { snmpRptrModCompls 1 }
-
- snmpRptrModComplRFC1516 MODULE-COMPLIANCE
- STATUS deprecated
- DESCRIPTION
- "********* THIS COMPLIANCE IS DEPRECATED **********
-
- Compliance for RFC 1516 and for backwards
- compatibility with single-repeater,
- 10Mb/s-only implementations."
-
- MODULE -- this module
- MANDATORY-GROUPS { snmpRptrGrpBasic1516 }
-
- GROUP snmpRptrGrpMonitor1516
- DESCRIPTION
- "Implementation of this optional group is
- recommended for systems which have the
- instrumentation to do performance monitoring."
-
- GROUP snmpRptrGrpAddrTrack1516
- DESCRIPTION
- "Implementation of this group is
- recommended for systems which have
- the necessary instrumentation."
-
-
-
- de Graaf, et. al. Standards Track [Page 72]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- ::= { snmpRptrModCompls 2 }
-
- snmpRptrModCompl MODULE-COMPLIANCE
- STATUS current
- DESCRIPTION
- "Compliance for the multi-segment version of the
- MIB module for a system with one or more
- repeater-units."
-
- MODULE -- this module
- MANDATORY-GROUPS { snmpRptrGrpBasic,
- snmpRptrGrpMonitor,
- snmpRptrGrpAddrTrack }
-
- GROUP snmpRptrGrpMonitor100
- DESCRIPTION
- "Implementation of this group is
- mandatory for managed systems which
- contain 100Mb/s repeaters."
-
- GROUP snmpRptrGrpMonitor100w64
- DESCRIPTION
- "Implementation of this group is
- mandatory for managed systems which
- contain 100Mb/s repeaters and which
- can support Counter64."
-
- GROUP snmpRptrGrpExtAddrTrack
- DESCRIPTION
- "Implementation of this group is
- recommended for systems which have
- the necessary instrumentation to track
- MAC addresses of multiple DTEs attached
- to a single repeater port."
-
- GROUP snmpRptrGrpRptrAddrSearch
- DESCRIPTION
- "Implementation of this group is
- recommended for systems which allow
- read-write access and which have
- the necessary instrumentation to
- search all incoming data streams
- for a particular MAC address."
-
- GROUP snmpRptrGrpTopNPort
- DESCRIPTION
- "Implementation of this group is
- recommended for systems which have
-
-
-
- de Graaf, et. al. Standards Track [Page 73]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- the necessary resources to support
- TopN statistics reporting."
-
- ::= { snmpRptrModCompls 3 }
-
-
- END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- de Graaf, et. al. Standards Track [Page 74]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- 4. Topology Mapping
-
- The network mapping algorithm presented below takes information
- available from network devices such as repeaters, bridges, and
- switches, and creates a representation of the physical topology of
- the network.
-
- Networking devices connect to the network via one or more ports.
- Through these ports, the device is capable of hearing network packets
- sent by other devices. By looking the source address in the packet,
- and identifying which port the packet was heard on, the device can
- provide information to a Network Management System about the location
- of an address in the network, relative to that device. For devices
- such as bridges and switches, the association of address to port can
- be retrieved via the forwarding data base part of the Bridge MIB.
- For repeaters, the rptrAddrSearchTable may be used to perform the
- association.
-
- Given this information, it would be possible for the NMS to create a
- topology of the network which represents the physical relationships
- of the devices in the networks. The following is an example of how
- this might be done:
-
- Assume the network:
-
- =============================
- | | |
- | | |
- d1 d4 d7
- / \ |
- / \ |
- d2 d3 d5
- |
- |
- d6
-
- The discovery process would first determine the existence of the
- network devices and nodes in the network. In the above example, the
- network devices discovered would be:
-
- d1,d2,d3,d4,d5,d6,d7
-
- From this list of discovered devices, select (arbitrarily or via some
- heuristic) a device as the starting point. From that device,
- determine where all other devices are located in the network with
- respect to the selected device.
-
-
-
-
-
- de Graaf, et. al. Standards Track [Page 75]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- For example, if d1 is the selected device, the network in relation to
- d1 would look like:
-
- d1
- / | \
- / | \
- d2 d3 d4,d5,d6,d7
-
- So d1 sees d2 on one port, d3 on another port, and d4, d5, and d6 on
- the third port. In other words, using the rptrAddrSearchTable (if d1
- is a repeater) or the Forwarding Database (if it is a bridge or a
- switch), d1 has located d2 on one port, d1 has located d3 on another
- port, and finally, d1 has located d4, d5, d6, and d7 on yet another
- port.
-
- After the first step of the algorithm is accomplished, the next and
- final step is a recursive one. Go to each of these temporary
- 'segments' (e.g., the segment connecting d1 and d2, or the segment
- connecting d1 and d3, or the segment connecting d1, d4, d5, d6, and
- d7) and determine which of these devices really belongs in that
- segment.
-
- As new segments are created due to this process, the recursive
- algorithm visits them, and performs the exact same process.
-
- In the example, the segments connecting d1 and d2, and connecting d1
- and d3, require no further scrutiny, since there are only two nodes
- in those segments. However, the segment connecting d1, d4, d5, d6,
- and d7 may prove to be one or more segments, so we will investigate
- it.
-
- The purpose of this step is to determine which devices are really
- connected to this segment, and which are actually connected
- downstream. This is done by giving each of the child devices in the
- segment (d4, d5, d6, and d7) a chance to eliminate each of the others
- from the segment.
-
- A device eliminates another device by showing that it hears the
- parent device (in this case, d1) on one port, and the other device on
- another port (different from the port on which it heard the parent).
- If this is true, then it must mean that that device is _between_ the
- parent device and the device which is being eliminated.
-
-
-
-
-
-
-
-
-
- de Graaf, et. al. Standards Track [Page 76]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- In the example, we can see that device d4 can eliminate both d5 and
- d6, , but nobody can eliminate d4 and d7, because everybody hears
- them on the same port that they hear the parent device (d1). So the
- resulting topology looks like:
-
- d1
- / | \
- / | \
- d2 d3 d4,d7
- |
- |
- d5,d6
-
- Next the algorithm visits the next segment, which is the one
- connecting d4, d5, and d6. Using the process stated above, d5 can
- eliminate d6, since it hears d4 on a different port from where it
- hears d6. Finally, the topology looks like:
-
- d1
- / | \
- / | \
- d2 d3 d4,d7
- |
- |
- d5
- |
- |
- d6
-
-
- This is actually the topology shown at the beginning of the
- description.
-
- With this information about how the network devices are connected, it
- is a relatively simple extension to then place nodes such as
- workstations and PCs in the network. This can be done by placing the
- node into a segment, then allowing the network devices to show that
- the node is really not part of that segment.
-
- This elimination can be done because the devices know what port
- connects them to the segment on which the node is temporarily placed.
- If they actually hear the node on a different port than that which
- connects the device to the segment, then the node must be downstream,
- and so it is moved onto the downstream segment. Then that segment is
- evaluated, and so forth. Eventually, no device can show that the
- node is connected downstream, and so it must be attached to that
- segment.
-
-
-
-
- de Graaf, et. al. Standards Track [Page 77]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- For example, assume the network:
-
- =============================
- | | |
- | | |
- d1 d4 d7
- / \ |
- / \ |
- d2 d3 d5
- | |
- | |
- e1 d6
-
- In this network, we are trying to place e1 where it belongs. We
- begin by placing it arbitrarily into a segment:
-
- ==================================
- | | | |
- | | | |
- e1 d1 d4 d7
- / \ |
- / \ |
- d2 d3 d5
- |
- |
- d6
-
- In the above case, we would give d1, d4, and d7 a chance to show that
- e1 is not really on that segment. d4 and d7 hear e1 on the same port
- which connects them to that segment, so they cannot eliminate e1 from
- the segment. However, d1 will hear e1 on a different port, so we
- move e1 down onto the segment which is connected by that port. This
- yields the following:
-
- =============================
- | | |
- | | |
- d1 d4 d7
- / \ |
- / \ |
- d2 d3,e1 d5
- |
- |
- d6
-
-
-
-
-
-
-
- de Graaf, et. al. Standards Track [Page 78]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- Now we give everyone in that segment (besides that parent device, d1)
- a chance to eliminate e1. Only d3 can try, and it succeeds, so we
- place e1 on segment which is connected by the port on which d3 heard
- e1. There is no segment there (yet), so we create one, and end up
- with the following:
-
- =============================
- | | |
- | | |
- d1 d4 d7
- / \ |
- / \ |
- d2 d3 d5
- | |
- | |
- e1 d6
-
- which is the correct position.
-
- 5. Acknowledgements
-
-
- This document was produced by the IETF Hub MIB Working Group, whose
- efforts were greatly advanced by the contributions of the following
- people:
-
- Chuck Black
- John Flick
- Jeff Johnson
- Leon Leong
- Mike Lui
- Dave Perkins
- Geoff Thompson
- Maurice Turcotte
- Paul Woodruff
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- de Graaf, et. al. Standards Track [Page 79]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- 6. References
-
- [1] IEEE 802.3/ISO 8802-3 Information processing systems -
- Local area networks - Part 3: Carrier sense multiple
- access with collision detection (CSMA/CD) access method
- and physical layer specifications, 1993.
-
- [2] IEEE 802.3u-1995, "MAC Parameters, Physical Layer, Medium
- Attachment Units and Repeater for 100 Mb/s Operation,
- Type 100BASE-T," Sections 21 through 29, Supplement to
- IEEE Std 802.3, October 26, 1995.
-
- [3] IEEE 802.3u-1995, "10 & 100 Mb/s Management," Section 30,
- Supplement to IEEE Std 802.3, October 26, 1995.
-
- [4] de Graaf, K., D. Romascanu, D. McMaster, K. McCloghrie,
- and S. Roberts, "Definitions of Managed Objects for IEEE
- 802.3 Medium Attachment Units (MAUs)", Work in Progress.
-
- [5] McCloghrie, K., and M. Rose, Editors, "Management
- Information Base for Network Management of TCP/IP-based
- internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems,
- Performance Systems International, March 1991.
-
- [6] SNMPv2 Working Group, J. Case, K. McCloghrie, M. Rose,
- and S. Waldbusser, "Structure of Management Information
- for version 2 of the Simple Network Management Protocol
- (SNMPv2)", RFC 1902, January 1996.
-
- [7] SNMPv2 Working Group, J. Case, K. McCloghrie, M. Rose,
- and S. Waldbusser, "Textual Conventions for version 2 of
- the Simple Network Management Protocol (SNMPv2)", RFC
- 1903, January 1996.
-
- [8] SNMPv2 Working Group, J. Case, K. McCloghrie, M. Rose,
- and S. Waldbusser, "Conformance Statements for version 2
- of the Simple Network Management Protocol (SNMPv2)", RFC
- 1904, January 1996.
-
- [9] SNMPv2 Working Group, J. Case, K. McCloghrie, M. Rose,
- and S. Waldbusser, "Protocol Operations for version 2 of
- the Simple Network Management Protocol (SNMPv2)", RFC
- 1905, January 1996.
-
-
-
-
-
-
-
-
- de Graaf, et. al. Standards Track [Page 80]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- [10] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "Simple
- Network Management Protocol", STD 15, RFC 1157, SNMP
- Research, Performance Systems International, MIT Laboratory
- for Computer Science, May 1990.
-
- [11] McMaster, D., and K. McCloghrie, "Definitions of Managed
- Objects for IEEE 802.3 Repeater Devices", RFC 1516,
- September 1993.
-
- [12] McAnally, G., D. Gilbert, and J. Flick, "Conditional
- Grant of Rights to Specific Hewlett-Packard Patents In
- Conjunction With the Internet Engineering Task Force's
- Internet-Standard Network Management Framework", RFC 1988,
- August 1996.
-
- [13] Hewlett-Packard Company, US Patents 5,293,635 and
- 5,421,024.
-
- [14] McCloghrie, K., and F. Kastenholz, "Evolution of the
- Interfaces Group of MIB-II", RFC 1573, January 1994.
-
- 7. Security Considerations
-
- Security issues are not discussed in this memo.
-
- 8. Authors' Addresses
-
- Kathryn de Graaf
- 3Com Corporation
- 118 Turnpike Rd.
- Southborough, MA 01772 USA
-
- Phone: (508)229-1627
- Fax: (508)490-5882
- EMail: kdegraaf@isd.3com.com
-
-
- Dan Romascanu
- Madge Networks (Israel) Ltd.
- Atidim Technology Park, Bldg. 3
- Tel Aviv 61131, Israel
-
- Phone: 972-3-6458414, 6458458
- Fax: 972-3-6487146
- EMail: dromasca@madge.com
-
-
-
-
-
-
- de Graaf, et. al. Standards Track [Page 81]
-
- RFC 2108 802.3 Repeater MIB using SMIv2 February 1997
-
-
- Donna McMaster
- Cisco Systems Inc.
- 170 West Tasman Drive
- San Jose, CA 95134
-
- Phone: (408) 526-5260
- EMail: mcmaster@cisco.com
-
-
- Keith McCloghrie
- Cisco Systems Inc.
- 170 West Tasman Drive
- San Jose, CA 95134
-
- Phone: (408) 526-5260
- EMail: kzm@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- de Graaf, et. al. Standards Track [Page 82]
-
-